perm filename F85[JNK,JMC] blob
sn#806988 filedate 1985-12-31 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00680 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00091 00002
C00092 00003 ∂06-Aug-85 0931 NISSENBAUM@SU-CSLI.ARPA CSLI Talk
C00093 00004 ∂06-Aug-85 1056 TRUDY@SU-CSLI.ARPA Julia Robinson
C00097 00005 ∂06-Aug-85 1102 TRUDY@SU-CSLI.ARPA Julia Robinson
C00098 00006 ∂06-Aug-85 1316 EMMA@SU-CSLI.ARPA Newsletter
C00099 00007 ∂06-Aug-85 1702 SBARNES@SUMEX-AIM.ARPA SIGLUNCH Friday August 9, 1985
C00107 00008 ∂06-Aug-85 1831 DAVIES@SUMEX-AIM.ARPA No meeting this week
C00108 00009 ∂06-Aug-85 1900 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #9
C00114 00010 ∂07-Aug-85 1133 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA NEXT MONDAY'S PLANLUNCH
C00117 00011 ∂07-Aug-85 1532 ullman@diablo paper received
C00119 00012 ∂07-Aug-85 1718 EMMA@SU-CSLI.ARPA Newsletter August 8, No. 40
C00128 00013 ∂08-Aug-85 1244 YAMARONE@SU-CSLI.ARPA SANDWICH ORDERS <9:30
C00130 00014 ∂08-Aug-85 1320 SELLS@SU-CSLI.ARPA using Imprint
C00132 00015 ∂08-Aug-85 1527 PIERRE@SU-CSLI.ARPA Printing DVI files
C00133 00016 ∂09-Aug-85 0944 BETSY@SU-CSLI.ARPA SDF Visit
C00135 00017 ∂09-Aug-85 1340 DAVIES@SUMEX-AIM.ARPA Advanced Architecture Meeting Wednesday August 14!!
C00136 00018 ∂11-Aug-85 1837 ULLMAN@SU-SCORE.ARPA ["Prof. David Maier" <maier%oregon-grad.csnet@csnet-relay.arpa>: Complexity of LP evaluation]
C00140 00019 ∂11-Aug-85 2059 DAVIES@SUMEX-AIM.ARPA New mailing list: CARE-Users
C00142 00020 ∂11-Aug-85 2138 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #10
C00153 00021 ∂12-Aug-85 1244 YAMARONE@SU-CSLI.ARPA Extra Turkey Sandwich
C00154 00022 ∂12-Aug-85 1303 @SU-CSLI.ARPA:GEORGEFF@SRI-AI.ARPA Monday Planlunch
C00157 00023 ∂13-Aug-85 1027 ullman@diablo tomorrow's meeting
C00162 00024 ∂13-Aug-85 1040 ullman@diablo another talk
C00165 00025 ∂13-Aug-85 1225 YAMARONE@SU-CSLI.ARPA Two Turkey Sands.Available
C00166 00026 ∂13-Aug-85 1548 ullman@diablo Porter paper
C00167 00027 ∂13-Aug-85 1611 vardi@diablo Re: Porter paper
C00168 00028 ∂13-Aug-85 1937 YM@SU-AI.ARPA Seminar on Control in Prolog
C00171 00029 ∂13-Aug-85 2205 @MIT-MC.ARPA:HEWITT@MIT-MC.ARPA Prolog will fail as the foundation for AI so will LOGIC as a PROGRAMMING Language
C00174 00030 ∂13-Aug-85 2332 DAVIES@SUMEX-AIM.ARPA QLISP on CARE
C00187 00031 ∂14-Aug-85 0115 @MIT-MC.ARPA:Wayne@MIT-OZ Prolog will fail as the foundation for AI so will LOGIC as a PROGRAMMING Language
C00197 00032 ∂14-Aug-85 0243 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #11
C00231 00033 ∂14-Aug-85 0922 @MIT-MC.ARPA:DAM@MIT-OZ Symbolics Prolog
C00233 00034 ∂14-Aug-85 0936 @SU-CSLI.ARPA:barwise.pa@Xerox.ARPA Robin Cooper's Title
C00235 00035 ∂14-Aug-85 0958 @MIT-MC.ARPA:Vijay.Saraswat@CMU-CS-C.ARPA On logic programming as a foundation for AI.
C00253 00036 ∂14-Aug-85 1107 @MIT-MC.ARPA:Laws@SRI-AI.ARPA Challenge Problem
C00258 00037 ∂14-Aug-85 1258 NET-ORIGIN@MIT-MC.ARPA Re: Prolog will fail as the foundation for AI so will LOGIC as a PROGRAMMING Language
C00265 00038 ∂14-Aug-85 1614 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA PLANLUNCH break -- for next three weeks
C00267 00039 ∂14-Aug-85 1743 EMMA@SU-CSLI.ARPA Newsletter August 15, No. 41
C00279 00040 ∂15-Aug-85 0819 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa THE SEVENTH THEORY DAY at Columbia University
C00282 00041 ∂15-Aug-85 0831 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa my new address
C00284 00042 ∂15-Aug-85 1425 ullman@diablo papers received
C00286 00043 ∂16-Aug-85 0125 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #12
C00294 00044 ∂16-Aug-85 0925 ullman@diablo a random thought before I forget it
C00296 00045 ∂16-Aug-85 1010 PAPA@SU-SCORE.ARPA Re: a random thought before I forget it
C00298 00046 ∂17-Aug-85 1306 BRAD@SU-CSLI.ARPA System clock
C00299 00047 ∂18-Aug-85 1216 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa birth announcement
C00301 00048 ∂18-Aug-85 1505 @SU-SUSHI.ARPA:ANDERSON@SU-SCORE.ARPA Thesis Orals, August 22
C00303 00049 ∂18-Aug-85 1535 ACUFF@SUMEX-AIM.ARPA Local BUG-LISPM
C00305 00050 ∂19-Aug-85 0948 @MIT-MC.ARPA:Hewitt@MIT-MC.ARPA Prolog will fail as the foundation for AI so will LOGIC as a PROGRAMMING Language
C00318 00051 ∂19-Aug-85 1005 ullman@diablo events this week
C00321 00052 ∂19-Aug-85 1516 avg@diablo linear approximations
C00327 00053 ∂19-Aug-85 1620 @MIT-MC.ARPA:august@JPL-VLSI.ARPA Got to keep trying! Sorry about all the copies.
C00330 00054 ∂19-Aug-85 2011 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #36
C00362 00055 ∂20-Aug-85 1240 @SU-SUSHI.ARPA:ANDERSON@SU-SCORE.ARPA Complexity Year info
C00365 00056 ∂20-Aug-85 2251 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa "Official" FOCS airline
C00369 00057 ∂20-Aug-85 2302 ullman@diablo
C00372 00058 ∂20-Aug-85 2302 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa Roommates for FOCS
C00376 00059 ∂21-Aug-85 0912 EMMA@SU-CSLI.ARPA Ventura Hall and air conditioning
C00378 00060 ∂21-Aug-85 0925 ullman@diablo don't forget
C00379 00061 ∂21-Aug-85 1158 STUCKY@SU-CSLI.ARPA D-lion Users
C00382 00062 ∂21-Aug-85 1658 ullman@diablo paper received
C00383 00063 ∂21-Aug-85 1736 EMMA@SU-CSLI.ARPA Newsletter August 22, No. 42
C00394 00064 ∂21-Aug-85 2018 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:Robert←S.←Printis.osbunorth@Xerox.ARPA Re: Complexity Year info
C00396 00065 ∂22-Aug-85 1609 MARJORIE@SU-CSLI.ARPA phone lines
C00397 00066 ∂22-Aug-85 1651 JAMIE@SU-CSLI.ARPA security
C00398 00067 ∂22-Aug-85 2229 JAMIE@SU-CSLI.ARPA security
C00400 00068 ∂23-Aug-85 0905 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa Messages to SIAM
C00402 00069 ∂25-Aug-85 0130 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #13
C00408 00070 ∂25-Aug-85 1031 DAVIES@SUMEX-AIM.ARPA Vacation
C00409 00071 ∂26-Aug-85 0059 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #36
C00441 00072 ∂26-Aug-85 0845 EMMA@SU-CSLI.ARPA Mailing lists
C00442 00073 ∂26-Aug-85 1033 ACUFF@SUMEX-AIM.ARPA Explorer
C00444 00074 ∂26-Aug-85 1141 STUCKY@SU-CSLI.ARPA D-Lion Users
C00446 00075 ∂26-Aug-85 1434 ullman@diablo surprise visit
C00448 00076 ∂30-Aug-85 1301 PATASHNIK@SU-SUSHI.ARPA [karp%ucbernie@Berkeley (Richard Karp):]
C00450 00077 ∂30-Aug-85 1324 ullman@diablo meeting today
C00451 00078 ∂30-Aug-85 1327 chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--September 3rd
C00458 00079 ∂30-Aug-85 1342 HANS@SU-CSLI.ARPA talk by Uwe Reyle
C00459 00080 ∂30-Aug-85 1348 EMMA@SU-CSLI.ARPA parking stickers
C00461 00081 ∂30-Aug-85 1355 @SU-CSLI.ARPA:chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--September 3rd
C00468 00082 ∂30-Aug-85 1407 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa moving
C00471 00083 ∂30-Aug-85 1409 EMMA@SU-CSLI.ARPA Re: parking stickers
C00473 00084 ∂30-Aug-85 1427 EMMA@SU-CSLI.ARPA Newsletter August 29, No. 43
C00483 00085 ∂30-Aug-85 1626 NEUMANN@SRI-CSLA.ARPA RISKS-1.3, 30 Aug 85
C00495 00086 ∂01-Sep-85 2356 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa IJPP: new journal on parallel programming
C00504 00087 ∂02-Sep-85 1406 @SU-SUSHI.ARPA:PAPA@SU-SCORE.ARPA Ride for Berkeley
C00505 00088 ∂02-Sep-85 2235 NEUMANN@SRI-CSLA.ARPA RISKS-1.4, 02 Sep 85
C00520 00089 ∂03-Sep-85 1004 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa call for papers - MIT conference on VLSI
C00528 00090 ∂03-Sep-85 1530 ullman@diablo paper received
C00530 00091 ∂03-Sep-85 1654 RICE@SUMEX-AIM.ARPA Wednesday's Meeting
C00532 00092 ∂03-Sep-85 1815 BRAD@SU-CSLI.ARPA vacation
C00533 00093 ∂04-Sep-85 1038 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
C00536 00094 ∂04-Sep-85 1346 chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--Sept 10
C00541 00095 ∂04-Sep-85 1354 @SU-CSLI.ARPA:chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--Sept 10
C00546 00096 ∂04-Sep-85 1408 STUCKY@SU-CSLI.ARPA Dlion-users
C00548 00097 ∂04-Sep-85 1736 EMMA@SU-CSLI.ARPA Newsletter September 5, No. 44
C00563 00098 ∂04-Sep-85 2123 NEUMANN@SRI-CSLA.ARPA RISKS-1.5, 04 Sep 85
C00587 00099 ∂05-Sep-85 1640 EMMA@SU-CSLI.ARPA New project mailing lists
C00591 00100 ∂06-Sep-85 0048 NEUMANN@SRI-CSLA.ARPA RISKS-1.6, 06 Sep 85
C00613 00101 ∂08-Sep-85 0149 NEUMANN@SRI-CSLA.ARPA RISKS-1.7, 08 Sep 85
C00659 00102 ∂08-Sep-85 1840 NEUMANN@SRI-CSLA.ARPA RISKS-1.8, 08 Sep 85, 2nd issue today!
C00692 00103 ∂09-Sep-85 1257 YAMARONE@SU-CSLI.ARPA ONE EXTRA SANDWICH:TURKEY/LT.RYE
C00693 00104 ∂09-Sep-85 1337 SUSI@SU-CSLI.ARPA
C00694 00105 ∂09-Sep-85 1417 CAROL@SU-CSLI.ARPA DANDELION ASSISTANCE
C00697 00106 ∂09-Sep-85 1517 @SU-CSLI.ARPA:GEORGEFF@SRI-AI.ARPA PLANLUNCH resumes next week
C00699 00107 ∂09-Sep-85 2134 NEUMANN@SRI-CSLA.ARPA RISKS-1.9, 09 Sep 85
C00712 00108 ∂09-Sep-85 2347 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #14
C00736 00109 ∂10-Sep-85 1014 RICE@SUMEX-AIM.ARPA Tomorrow's Meeting.
C00737 00110 ∂10-Sep-85 1402 RICHARDSON@SU-SCORE.ARPA Sr. Faculty Meeting
C00738 00111 ∂10-Sep-85 2130 ullman@diablo weird message
C00739 00112 ∂11-Sep-85 1239 BETSY@SU-CSLI.ARPA CSLI Activities in 1985-86
C00748 00113 ∂11-Sep-85 1741 EMMA@SU-CSLI.ARPA Newsletter September 12, No. 45
C00757 00114 ∂11-Sep-85 1742 BRESNAN@SU-CSLI.ARPA Valentina Zavarin
C00759 00115 ∂12-Sep-85 0323 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:klawe.sjrlvm1%ibm-sj.csnet@csnet-relay.arpa talk on razborov's theorem
C00761 00116 ∂12-Sep-85 0905 chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--Sept. 17
C00766 00117 ∂12-Sep-85 0908 @SU-CSLI.ARPA:chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--Sept. 17
C00772 00118 ∂12-Sep-85 0932 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa FOCS reminders
C00776 00119 ∂12-Sep-85 1208 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Next week's PLANLUNCH -- notice change in date, place
C00780 00120 ∂12-Sep-85 1353 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp%ucbernie@Berkeley
C00783 00121 ∂12-Sep-85 1422 BARWISE@SU-CSLI.ARPA TGBBQ
C00784 00122 ∂12-Sep-85 1424 NEUMANN@SRI-CSLA.ARPA RISKS-1.10
C00785 00123 ∂12-Sep-85 1540 NEUMANN@SRI-CSLA.ARPA RISKS-1.10
C00801 00124 ∂12-Sep-85 1628 NEUMANN@SRI-CSLA.ARPA The foregoing mailings of RISKS-1.10
C00804 00125 ∂12-Sep-85 1750 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa
C00807 00126 ∂13-Sep-85 0151 NEUMANN@SRI-CSLA.ARPA RISKS-1.11
C00832 00127 ∂13-Sep-85 0307 NET-ORIGIN@MIT-MC.ARPA Enter on BBoard
C00835 00128 ∂13-Sep-85 0855 ullman@su-aimvax.arpa meeting
C00836 00129 ∂13-Sep-85 1117 BETSY@SU-CSLI.ARPA New Charge for Specially Processed Checks
C00838 00130 ∂13-Sep-85 1209 @MIT-MC.ARPA:Ghenis.pasa@XEROX.ARPA Is the Phi of Sci list alive?
C00840 00131 ∂13-Sep-85 1218 YAMARONE@SU-CSLI.ARPA TGIF TODAY @ 4:00
C00845 00132 ∂13-Sep-85 1302 YAMARONE@SU-CSLI.ARPA ONE EXTRA TURKEY SANDWICH:2.50
C00846 00133 ∂13-Sep-85 1505 NEUMANN@SRI-CSLA.ARPA RISKS-1.12
C00862 00134 ∂13-Sep-85 1636 NEUMANN@SRI-CSLA.ARPA RISKS-1.12
C00878 00135 ∂15-Sep-85 0339 NEUMANN@SRI-CSLA.ARPA RISKS-1.13
C00898 00136 ∂15-Sep-85 1200 CS.AVI@R20.UTEXAS.EDU PODS call for paper
C00904 00137 ∂15-Sep-85 1251 @MIT-MC.ARPA:7thSon@SCRC-STONY-BROOK.ARPA philosophy of science
C00906 00138 ∂15-Sep-85 1307 @MIT-MC.ARPA:7thSon@SCRC-STONY-BROOK.ARPA philosophy of science
C00908 00139 ∂16-Sep-85 0135 @SUMEX-AIM.ARPA:SAMUEL@SU-SUSHI.ARPA SIGBIG
C00912 00140 ∂16-Sep-85 1004 EMMA@SU-CSLI.ARPA CSLI talk
C00915 00141 ∂16-Sep-85 2057 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp%ucbernie@Berkeley
C00917 00142 ∂16-Sep-85 2307 NEUMANN@SRI-CSLA.ARPA RISKS-1.14
C00939 00143 ∂16-Sep-85 2355 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #15
C00946 00144 ∂17-Sep-85 0027 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #16
C00957 00145 ∂17-Sep-85 0911 ullman@su-aimvax.arpa meeting
C00959 00146 ∂17-Sep-85 0918 ullman@su-aimvax.arpa paper recieved
C00960 00147 ∂17-Sep-85 0922 RICHARDSON@SU-SCORE.ARPA Sr. Faculty Meeting September 24
C00962 00148 ∂17-Sep-85 1140 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA PLANLUNCH REMINDER -- Wednesday, 11AM
C00965 00149 ∂17-Sep-85 1523 ullman@su-aimvax.arpa papers received
C00966 00150 ∂17-Sep-85 1622 MARJORIE@SU-CSLI.ARPA Books
C00967 00151 ∂17-Sep-85 2008 PIERRE@SU-CSLI.ARPA Books
C00968 00152 ∂18-Sep-85 0133 ACUFF@SUMEX-AIM.ARPA Explorer Mailing Lists
C00970 00153 ∂18-Sep-85 1536 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH
C00974 00154 ∂18-Sep-85 1615 SUSI@SU-CSLI.ARPA opportunity to share
C00975 00155 ∂18-Sep-85 2111 davies%ucbcogsci@Berkeley UCB Cognitive Science Seminar, Sept. 24, 1985
C00981 00156 ∂18-Sep-85 2112 @SU-CSLI.ARPA:davies%ucbcogsci@Berkeley UCB Cognitive Science Seminar, Sept. 24, 1985
C00987 00157 ∂19-Sep-85 0850 EMMA@SU-CSLI.ARPA Newsletter September 19, No. 46
C01001 00158 ∂20-Sep-85 0040 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa separating DL and NL using an oracle ?
C01004 00159 ∂20-Sep-85 1019 VSINGH@SUMEX-AIM.ARPA Comments
C01006 00160 ∂20-Sep-85 1211 NEUMANN@SRI-CSLA.ARPA RISKS-1.15
C01029 00161 ∂20-Sep-85 1248 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
C01033 00162 ∂20-Sep-85 1751 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa Final FOCS Forewarning
C01036 00163 ∂20-Sep-85 2106 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa parallel machine bibliography
C01039 00164 ∂21-Sep-85 1550 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #17
C01051 00165 ∂22-Sep-85 2315 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA PLANLUNCH reminder
C01055 00166 ∂23-Sep-85 0342 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #18
C01077 00167 ∂23-Sep-85 0651 PATASHNIK@SU-SUSHI.ARPA AFLB resumes
C01079 00168 ∂23-Sep-85 0847 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa Reminder, COming up this Friday
C01082 00169 ∂23-Sep-85 1005 RICHARDSON@SU-SCORE.ARPA Sr. Faculty Meeting
C01083 00170 ∂23-Sep-85 2016 PATASHNIK@SU-SUSHI.ARPA [Andrew Yao <YAO@SU-SCORE.ARPA>: Lower Bound Course]
C01085 00171 ∂24-Sep-85 1119 HAUNGA@SUMEX-AIM.ARPA Title and abstract for the SIGLUNCH, September 27th.
C01089 00172 ∂24-Sep-85 1144 REULING@SU-SCORE.ARPA LOTS Registration
C01091 00173 ∂24-Sep-85 1144 @SU-CSLI.ARPA:KAELBLING@SRI-AI.ARPA Course Announcement
C01094 00174 ∂24-Sep-85 1209 @SU-SCORE.ARPA:TW@SU-AI.ARPA Program for this year's computer forum
C01098 00175 ∂24-Sep-85 1317 MARJORIE@SU-CSLI.ARPA CSLI Computing pamphlet
C01100 00176 ∂24-Sep-85 1346 LIBRARY@SU-SCORE.ARPA Socrates: New Forms, What To Do If You Misplaced Your Old Account
C01103 00177 ∂24-Sep-85 1400 BSCOTT@SU-SCORE.ARPA Salaries
C01105 00178 ∂24-Sep-85 1412 DAVIES@SUMEX-AIM.ARPA No architecture meeting this week
C01106 00179 ∂24-Sep-85 1544 LIBRARY@SU-SCORE.ARPA Math/CS Library: New Books
C01108 00180 ∂24-Sep-85 1722 @SU-CSLI.ARPA:KAELBLING@SRI-AI.ARPA Room Change
C01109 00181 ∂24-Sep-85 1941 @SU-SCORE.ARPA:fournier@su-navajo.arpa Re: Socrates: New Forms, What To Do If You Misplaced Your Old Account
C01111 00182 ∂24-Sep-85 1951 @SU-SCORE.ARPA:fournier@su-navajo.arpa Re: Socrates: New Forms, What To Do If You Misplaced Your Old Account
C01113 00183 ∂25-Sep-85 0104 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #37
C01145 00184 ∂25-Sep-85 1133 CONTRERAS@SU-SCORE.ARPA Parking Stickers
C01146 00185 ∂25-Sep-85 1202 @SU-SCORE.ARPA:MDIXON@SU-SUSHI.ARPA maps to new student lunch
C01148 00186 ∂25-Sep-85 1353 CHEADLE@SU-SCORE.ARPA Reminder--CSD Reception tomorrow
C01150 00187 ∂25-Sep-85 1408 REGES@SU-SCORE.ARPA Department Lecture Series
C01152 00188 ∂25-Sep-85 1412 @SU-CSLI.ARPA:chertok%ucbcogsci@Berkeley.EDU UCB Cognitive Science Seminar--Oct. 1
C01157 00189 ∂25-Sep-85 1738 EMMA@SU-CSLI.ARPA Newsletter September 26, No. 47
C01179 00190 ∂25-Sep-85 2035 JF@SU-SUSHI.ARPA BATS at Berkeley 10/11/85
C01180 00191 ∂26-Sep-85 0059 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #38
C01206 00192 ∂26-Sep-85 0751 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #39
C01222 00193 ∂26-Sep-85 1048 @SU-SUSHI.ARPA:MAYR@SU-SCORE.ARPA talk by Marc Snir
C01225 00194 ∂26-Sep-85 1539 NEUMANN@SRI-CSLA.ARPA RISKS-1.16
C01249 00195 ∂26-Sep-85 1704 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Monday's PLANLUNCH
C01253 00196 ∂26-Sep-85 2229 sinha%gmr.csnet@CSNET-RELAY.ARPA add sinha@gmr to NAIL
C01254 00197 ∂27-Sep-85 0153 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #40
C01276 00198 ∂27-Sep-85 0902 NEUMANN@SRI-CSLA.ARPA RISKS-1.17
C01300 00199 ∂27-Sep-85 0930 JOHN@SU-CSLI.ARPA Philosophy 287A
C01302 00200 ∂27-Sep-85 0934 BETSY@SU-CSLI.ARPA 1986 Site Visit
C01304 00201 ∂27-Sep-85 1554 BSCOTT@SU-SCORE.ARPA Lost Articles, Yesterday's Reception
C01306 00202 ∂27-Sep-85 1606 LIBRARY@SU-SCORE.ARPA Math/CS Library Fall Hours
C01307 00203 ∂27-Sep-85 1615 LIBRARY@SU-SCORE.ARPA Socrates: New Version To Be Activated On Sunday, September 29th
C01310 00204 ∂29-Sep-85 1439 @SU-SCORE.ARPA:lantz@su-gregorio.arpa Re: speaking at orientation day
C01313 00205 ∂30-Sep-85 0157 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #41
C01337 00206 ∂30-Sep-85 0221 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #19
C01360 00207 ∂30-Sep-85 0829 PATASHNIK@SU-SUSHI.ARPA Abstracts
C01365 00208 ∂30-Sep-85 0935 RICHARDSON@SU-SCORE.ARPA Tuesday Lunch Series
C01366 00209 ∂30-Sep-85 1359 DAVIES@SUMEX-AIM.ARPA No meeting this week
C01368 00210 ∂30-Sep-85 1417 NILSSON@SU-SCORE.ARPA Course Schedule Policy
C01372 00211 ∂30-Sep-85 1430 MAYR@SU-SCORE.ARPA topics for prob. theory course
C01375 00212 ∂30-Sep-85 1828 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
C01378 00213 ∂30-Sep-85 2209 ACUFF@SUMEX-AIM.ARPA Explorer meets TCP
C01380 00214 ∂01-Oct-85 0855 RICHARDSON@SU-SCORE.ARPA Tuesday Lunch Series
C01381 00215 ∂01-Oct-85 0903 JF@SU-SUSHI.ARPA Still need stanford speaker for 10/11/85 bats
C01382 00216 ∂01-Oct-85 0922 @SU-SCORE.ARPA:SHORTLIFFE@SUMEX-AIM.ARPA Re: topics for prob. theory course
C01385 00217 ∂01-Oct-85 1017 CLT Seminar on Logic and the Foundations of Mathematics
C01387 00218 ∂01-Oct-85 1039 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar on Logic and the Foundations of Mathematics
C01389 00219 ∂01-Oct-85 1150 ullman@su-aimvax.arpa meeting tomorrow
C01390 00220 ∂01-Oct-85 1227 avg@su-aimvax.arpa Re: meeting tomorrow
C01391 00221 ∂01-Oct-85 1340 HAUNGA@SUMEX-AIM.ARPA Title for Siglunch - Friday Oct 4
C01392 00222 ∂01-Oct-85 1525 LIBRARY@SU-SCORE.ARPA Socrates: SELECT 9 for Technical Reports
C01395 00223 ∂01-Oct-85 1600 RICHARDSON@SU-SCORE.ARPA Pre-Colloquium Cookie Time
C01396 00224 ∂01-Oct-85 1636 MARJORIE@SU-CSLI.ARPA key
C01397 00225 ∂01-Oct-85 1723 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Monday Planlunch Reminder!
C01401 00226 ∂01-Oct-85 1726 POLLARD@SU-CSLI.ARPA new entity
C01402 00227 ∂02-Oct-85 0920 JOHN@SU-CSLI.ARPA Wheels for Wheels
C01405 00228 ∂02-Oct-85 1030 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ucbernie.Berkeley.EDU
C01408 00229 ∂02-Oct-85 1248 admin@ucbcogsci.Berkeley.EDU UCB Cognitive Science Seminar--Oct. 8 (Terry Winograd, Stanford)
C01414 00230 ∂02-Oct-85 1248 @SU-CSLI.ARPA:admin@ucbcogsci.Berkeley.EDU UCB Cognitive Science Seminar--Oct. 8 (Terry Winograd, Stanford)
C01420 00231 ∂02-Oct-85 1305 CHEADLE@SU-SCORE.ARPA Hopeful Ph.D. Grads
C01422 00232 ∂02-Oct-85 1323 LIBRARY@SU-SCORE.ARPA Socrates: Display to account--SUSHI problem
C01424 00233 ∂02-Oct-85 1352 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
C01428 00234 ∂02-Oct-85 1410 LIBRARY@SU-SCORE.ARPA Math/CS Library: New Reference Books--Guide to CS literature, Industrial Robotics Handbook, Computer-Readable Databas
C01430 00235 ∂02-Oct-85 1524 STUCKY@SU-CSLI.ARPA Bibliography Files
C01433 00236 ∂02-Oct-85 1713 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #20
C01441 00237 ∂02-Oct-85 1726 EMMA@SU-CSLI.ARPA addendum to the newsletter
C01442 00238 ∂02-Oct-85 1744 EMMA@SU-CSLI.ARPA Newsletter October 3, No. 48
C01451 00239 ∂03-Oct-85 0750 HAUNGA@SUMEX-AIM.ARPA title and abstract for SIGLUNCH Friday 4th.
C01454 00240 ∂03-Oct-85 1038 NILSSON@SU-SCORE.ARPA 5-year Plan
C01457 00241 ∂03-Oct-85 1236 WINOGRAD@SU-CSLI.ARPA Environments group - Monday 12:00pm
C01462 00242 ∂03-Oct-85 1354 @SU-SUSHI.ARPA:broder@decwrl.ARPA Plane ticket swap wanted
C01464 00243 ∂04-Oct-85 1014 ACUFF@SUMEX-AIM.ARPA Symbolics Machines available at some ACM Conference
C01466 00244 ∂04-Oct-85 1214 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Next week's PLANLUNCH --- WEDNESDAY (not monday) OCT.9
C01471 00245 ∂04-Oct-85 1358 JAMIE@SU-CSLI.ARPA graduate student offices
C01473 00246 ∂04-Oct-85 1508 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
C01475 00247 ∂04-Oct-85 1554 NEUMANN@SRI-CSLA.ARPA RISKS-1.18
C01498 00248 ∂05-Oct-85 1030 JF@SU-SUSHI.ARPA Abstracts and other Information about 10/11/85 BATS
C01508 00249 ∂05-Oct-85 1701 @SU-CSLI.ARPA:barwise@csli-whitehead Linguistics Positions
C01510 00250 ∂07-Oct-85 0032 DAVIES@SUMEX-AIM.ARPA This week's meeting
C01512 00251 ∂07-Oct-85 0632 PATASHNIK@SU-SUSHI.ARPA Next AFLB
C01515 00252 ∂07-Oct-85 0815 EMMA@SU-CSLI.ARPA Logic Lunch
C01517 00253 ∂07-Oct-85 0819 HAUNGA@SUMEX-AIM.ARPA Title & abstract for the SIGLUNCH, Friday 11th.
C01520 00254 ∂07-Oct-85 0921 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
C01521 00255 ∂07-Oct-85 0949 ullman@su-aimvax.arpa meeting
C01523 00256 ∂07-Oct-85 1026 ullman@su-aimvax.arpa paper just received
C01525 00257 ∂07-Oct-85 1444 WASHINGTON@SUMEX-AIM.ARPA Siglunch location
C01527 00258 ∂07-Oct-85 1841 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar on Logic and the Foundations of Mathematics
C01530 00259 ∂07-Oct-85 1850 CLT Seminar on COMMON SENSE AND NON-MONOTONIC REASONING
C01536 00260 ∂08-Oct-85 0011 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu ICDT 86 - Call For Papers
C01543 00261 ∂08-Oct-85 0111 NEUMANN@SRI-CSL.ARPA RISKS-1.19
C01562 00262 ∂08-Oct-85 0912 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
C01563 00263 ∂08-Oct-85 0936 @SU-SCORE.ARPA:TW@SU-AI.ARPA Reminder about forum talks
C01565 00264 ∂08-Oct-85 1043 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
C01566 00265 ∂08-Oct-85 1424 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA PLANLUNCH mailing list
C01568 00266 ∂08-Oct-85 1724 ullman@su-aimvax.arpa meeting
C01569 00267 ∂08-Oct-85 1756 BSCOTT@SU-SCORE.ARPA No-Smoking Policy
C01572 00268 ∂08-Oct-85 1910 NEUMANN@SRI-CSL.ARPA RISKS-1.20
C01594 00269 ∂09-Oct-85 0008 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #21
C01607 00270 ∂09-Oct-85 0155 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #42
C01631 00271 ∂09-Oct-85 0954 HANRAHAN@SU-SCORE.ARPA petty cash
C01632 00272 ∂09-Oct-85 1024 @SU-SCORE.ARPA:ejm@su-shasta.arpa Re: topics for prob. theory course
C01633 00273 ∂09-Oct-85 1113 @SU-SCORE.ARPA:ejm@su-shasta.arpa Re: petty cash
C01634 00274 ∂09-Oct-85 1349 DAVIES@SUMEX-AIM.ARPA Alliant -- Computer Systems Seminar Today!!
C01636 00275 ∂09-Oct-85 1648 admin@ucbcogsci.Berkeley.EDU Cognitive Science Seminar--Oct. 15 (Ron Kaplan, Xerox PARC & Stanford)
C01643 00276 ∂09-Oct-85 1656 @SU-CSLI.ARPA:admin@ucbcogsci.Berkeley.EDU Cognitive Science Seminar--Oct. 15 (Ron Kaplan, Xerox PARC & Stanford)
C01650 00277 ∂09-Oct-85 1703 EMMA@SU-CSLI.ARPA Newsletter October 10, No. 49
C01678 00278 ∂09-Oct-85 1705 AAAI-OFFICE@SUMEX-AIM.ARPA Cog Science Society Proposal
C01684 00279 ∂09-Oct-85 1915 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA Call for Papers, Spring'86 CUG
C01688 00280 ∂09-Oct-85 2015 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ucbernie.Berkeley.EDU
C01693 00281 ∂10-Oct-85 0904 LIBRARY@SU-SCORE.ARPA Socrates: Are people having problems when they attempt to telnet to Socrates?
C01695 00282 ∂10-Oct-85 1107 DELAGI@SUMEX-AIM.ARPA "Volunteers"
C01698 00283 ∂10-Oct-85 1357 LIBRARY@SU-SCORE.ARPA [The Mailer Daemon <Mailer@SU-SCORE.ARPA>: Message of 10-Oct-85 13:49:31]
C01702 00284 ∂10-Oct-85 1408 CAROL@SU-CSLI.ARPA New office
C01703 00285 ∂11-Oct-85 0042 NEUMANN@SRI-CSL.ARPA RISKS-1.21
C01737 00286 ∂11-Oct-85 0804 BRESNAN@SU-CSLI.ARPA announcement of MSDI presentations
C01739 00287 ∂11-Oct-85 1315 PATASHNIK@SU-SUSHI.ARPA Speaker for October 17
C01740 00288 ∂11-Oct-85 1502 LIBRARY@SU-SCORE.ARPA Socrates: Workshops to be held in the Green Library
C01742 00289 ∂11-Oct-85 2217 BRESNAN@SU-CSLI.ARPA presentation by Peter Sells
C01743 00290 ∂12-Oct-85 0800 PATASHNIK@SU-SUSHI.ARPA AFLB Abstract
C01746 00291 ∂14-Oct-85 0755 @SUMEX-AIM.ARPA:HAUNGA@SU-SCORE.ARPA Title & Abstract for the Siglunch Friday 18th.
C01749 00292 ∂14-Oct-85 0851 RICHARDSON@SU-SCORE.ARPA Tuesday CSD Lunch
C01750 00293 ∂14-Oct-85 0907 @SUMEX-AIM.ARPA:HAUNGA@SU-SCORE.ARPA SPEAKER for Friday 18th SIGLUNCH is David Heckerman.
C01751 00294 ∂14-Oct-85 1231 CAROL@SU-CSLI.ARPA Phone number
C01752 00295 ∂14-Oct-85 1557 ACUFF@SUMEX-AIM.ARPA Explorer Update
C01753 00296 ∂14-Oct-85 1849 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #22
C01781 00297 ∂15-Oct-85 0820 DAVIES@SUMEX-AIM.ARPA Meeting at 9:30 Wednesday
C01782 00298 ∂15-Oct-85 0829 RICHARDSON@SU-SCORE.ARPA Tuesday Lunch Series
C01783 00299 ∂15-Oct-85 0932 ullman@su-aimvax.arpa meeting
C01785 00300 ∂15-Oct-85 1103 RICHARDSON@SU-SCORE.ARPA Tuesday CSD Lunch Series
C01786 00301 ∂22-Oct-85 1545 BARWISE@SU-CSLI.ARPA Logic Lunch
C01787 00302 ∂22-Oct-85 1828 HANRAHAN@SU-SCORE.ARPA petty cash
C01788 00303 ∂22-Oct-85 1859 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar on Logic and the Foundations of Mathematics
C01790 00304 ∂22-Oct-85 1908 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #43
C01817 00305 ∂22-Oct-85 1911 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
C01818 00306 ∂22-Oct-85 1915 ullman@su-aimvax.arpa meeting this week
C01820 00307 ∂22-Oct-85 1916 SELLS@SU-CSLI.ARPA Hinrichs dissertation
C01821 00308 ∂22-Oct-85 1919 BRESNAN@SU-CSLI.ARPA "Topic, Pronoun, and Agreement in Chichewa"
C01822 00309 ∂22-Oct-85 1919 LIBRARY@SU-SCORE.ARPA Math/CS Library: Electronic Services--If New To Stanford Please Read
C01826 00310 ∂22-Oct-85 1921 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ernie.Berkeley.EDU
C01828 00311 ∂22-Oct-85 1923 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #24
C01840 00312 ∂22-Oct-85 2055 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
C01841 00313 ∂22-Oct-85 2056 RICHARDSON@SU-SCORE.ARPA [The Mailer Daemon <Mailer@SU-SCORE.ARPA>: Message of 17-Oct-85 10:40:56]
C01844 00314 ∂22-Oct-85 2058 @SU-SCORE.ARPA:WINOGRAD@SU-CSLI.ARPA Postponement of PhD program meeting
C01846 00315 ∂23-Oct-85 0609 PATASHNIK@SU-SUSHI.ARPA AFLB abstracts
C01850 00316 ∂23-Oct-85 0749 @SU-CSLI.ARPA:RPERRAULT@SRI-AI.ARPA Talk by Bill Rounds
C01853 00317 ∂23-Oct-85 1048 CONTRERAS@SU-SCORE.ARPA Class Lists
C01854 00318 ∂23-Oct-85 1103 MODICA@SU-SCORE.ARPA Class Lists - Correction
C01855 00319 ∂23-Oct-85 1133 CONTRERAS@SU-SCORE.ARPA Mailboxes
C01856 00320 ∂23-Oct-85 1303 YAMARONE@SU-CSLI.ARPA R/B + swiss Available Now at Front Desk
C01857 00321 ∂23-Oct-85 1432 ullman@su-aimvax.arpa financial detail
C01859 00322 ∂23-Oct-85 1611 admin@cogsci.Berkeley.EDU UCB Cognitive Science Seminar--Oct. 29, 1985
C01864 00323 ∂23-Oct-85 1633 @SU-CSLI.ARPA:admin@cogsci.Berkeley.EDU UCB Cognitive Science Seminar--Oct. 29, 1985
C01869 00324 ∂23-Oct-85 1733 EMMA@SU-CSLI.ARPA Newsletter October 24, No. 51
C01893 00325 ∂24-Oct-85 0110 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #25
C01900 00326 ∂24-Oct-85 0819 EMMA@SU-CSLI.ARPA Today's CSLI seminar
C01901 00327 ∂24-Oct-85 0847 AAAI-OFFICE@SUMEX-AIM.ARPA New Tutorial Chair
C01903 00328 ∂24-Oct-85 1436 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
C01906 00329 ∂24-Oct-85 1514 ullman@su-aimvax.arpa Dave Smith's conjecture
C01913 00330 ∂24-Oct-85 1602 BETSY@SU-CSLI.ARPA Visitor Policy
C01919 00331 ∂24-Oct-85 1724 NILSSON@SU-SCORE.ARPA [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
C01922 00332 ∂24-Oct-85 2129 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #26
C01931 00333 ∂24-Oct-85 2231 BRESNAN@SU-CSLI.ARPA "Case-Assignment by Nominals in Japanese"
C01934 00334 ∂25-Oct-85 0030 DAVIES@SUMEX-AIM.ARPA Wednesday meeting -- 9 am
C01935 00335 ∂25-Oct-85 0935 BARWISE@SU-CSLI.ARPA Logic Seminar Cancelled today
C01936 00336 ∂25-Oct-85 0938 AAAI-OFFICE@SUMEX-AIM.ARPA Mark's confirmation
C01937 00337 ∂25-Oct-85 1018 INGRID@SU-CSLI.ARPA House for Rent
C01939 00338 ∂25-Oct-85 1032 INGRID@SU-CSLI.ARPA House for Rent
C01941 00339 ∂25-Oct-85 1036 @SU-CSLI.ARPA:CLT@SU-AI.ARPA todays logic seminar is cancelled
C01942 00340 ∂25-Oct-85 1036 RICHARDSON@SU-SCORE.ARPA November Sr. Faculty Meeting
C01943 00341 ∂25-Oct-85 1106 @SU-SCORE.ARPA:FEIGENBAUM@SUMEX-AIM.ARPA Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
C01945 00342 ∂25-Oct-85 1112 @SU-SCORE.ARPA:FEIGENBAUM@SUMEX-AIM.ARPA Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
C01947 00343 ∂25-Oct-85 1118 @SU-SCORE.ARPA:FEIGENBAUM@SUMEX-AIM.ARPA Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
C01949 00344 ∂25-Oct-85 1304 INGRID@SU-CSLI.ARPA Internal Faculty Fellowships
C01951 00345 ∂25-Oct-85 1433 ullman@su-aimvax.arpa papers received
C01952 00346 ∂25-Oct-85 1559 MODICA@SU-SCORE.ARPA Class Lists
C01953 00347 ∂26-Oct-85 1019 BRESNAN@SU-CSLI.ARPA "Case-Assignment by Nominals in Japanese"
C01954 00348 ∂27-Oct-85 1418 NILSSON@SU-SCORE.ARPA Student names
C01956 00349 ∂27-Oct-85 1447 NILSSON@SU-SCORE.ARPA Committees
C01973 00350 ∂27-Oct-85 1849 LANSKY@SRI-AI.ARPA PLANLUNCH REMINDER - Pat Hayes, Oct. 28
C01975 00351 ∂28-Oct-85 0143 @SU-SCORE.ARPA:manfred%ucsc.csnet@CSNET-RELAY.ARPA techreport request!
C01977 00352 ∂28-Oct-85 0834 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
C01978 00353 ∂28-Oct-85 0836 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar in Logic and the Foundations of Mathematics
C01980 00354 ∂28-Oct-85 1533 IIDA@SU-CSLI.ARPA Talk this Thursday by Masayo Iida
C01982 00355 ∂28-Oct-85 1624 @SU-SCORE.ARPA:pratt@su-navajo.arpa Student names
C01984 00356 ∂28-Oct-85 2233 @SU-SCORE.ARPA:HADDAD@SU-SUSHI.ARPA Re: Student names
C01988 00357 ∂29-Oct-85 0614 PATASHNIK@SU-SUSHI.ARPA AFLB abstracts
C01994 00358 ∂29-Oct-85 0907 MODICA@SU-SCORE.ARPA Class Lists
C01995 00359 ∂29-Oct-85 1011 TREITEL@SUMEX-AIM.ARPA Conjunct ordering
C02003 00360 ∂29-Oct-85 1129 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
C02004 00361 ∂29-Oct-85 1219 ullman@su-aimvax.arpa meeting
C02005 00362 ∂29-Oct-85 1537 CAROL@SU-CSLI.ARPA Demo of Dlion gloss package
C02008 00363 ∂29-Oct-85 1623 EMMA@SU-CSLI.ARPA Halloween
C02011 00364 ∂29-Oct-85 2334 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu FST&TCS 5th Conference
C02022 00365 ∂30-Oct-85 0615 PATASHNIK@SU-SUSHI.ARPA Special AFLB
C02026 00366 ∂30-Oct-85 0931 PHILOSOPHY@SU-CSLI.ARPA Josh Cohen
C02027 00367 ∂30-Oct-85 0931 PHILOSOPHY@SU-CSLI.ARPA Josh Cohen
C02028 00368 ∂30-Oct-85 1055 PHILOSOPHY@SU-CSLI.ARPA
C02029 00369 ∂30-Oct-85 1140 INGRID@SU-CSLI.ARPA Announcement
C02034 00370 ∂30-Oct-85 1155 @SU-SUSHI.ARPA:vemuri@ngp.UTEXAS.EDU Re: Special AFLB
C02035 00371 ∂30-Oct-85 1639 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH
C02038 00372 ∂30-Oct-85 1732 EMMA@SU-CSLI.ARPA Newsletter October 31, No. 52
C02060 00373 ∂31-Oct-85 0917 TAJNAI@SU-SCORE.ARPA 1985 IBM Party
C02062 00374 ∂31-Oct-85 0926 EMMA@SU-CSLI.ARPA Halloween 3
C02065 00375 ∂31-Oct-85 1323 EMMA@SU-CSLI.ARPA All Hallow's Eve
C02066 00376 ∂31-Oct-85 1450 EMMA@SU-CSLI.ARPA Halloween tea
C02067 00377 ∂31-Oct-85 1509 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
C02072 00378 ∂31-Oct-85 1952 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu VLSI workshop announcement
C02080 00379 ∂01-Nov-85 0040 ACUFF@SUMEX-AIM.ARPA Explorers working at last
C02082 00380 ∂01-Nov-85 0631 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 5
C02089 00381 ∂01-Nov-85 1030 ullman@su-aimvax.arpa talk today
C02090 00382 ∂01-Nov-85 1130 WINOGRAD@SU-CSLI.ARPA Lost coat
C02091 00383 ∂01-Nov-85 1203 COLEMAN@SU-CSLI.ARPA help the Aussies
C02093 00384 ∂01-Nov-85 1328 @SU-SCORE.ARPA:LES@SU-AI.ARPA Computer Facility Needs
C02100 00385 ∂01-Nov-85 1459 CHEADLE@SU-SCORE.ARPA Lost glasses
C02102 00386 ∂01-Nov-85 1604 RINDFLEISCH@SUMEX-AIM.ARPA IBM S.J. Research Computer Science seminars 4 - 8 NOV 85
C02111 00387 ∂01-Nov-85 1644 TAJNAI@SU-SCORE.ARPA honors
C02113 00388 ∂01-Nov-85 1656 INGRID@SU-CSLI.ARPA House for Rent
C02115 00389 ∂01-Nov-85 1752 COLEMAN@SU-CSLI.ARPA
C02116 00390 ∂01-Nov-85 1822 ACUFF@SUMEX-AIM.ARPA Leaving Explorers
C02117 00391 ∂01-Nov-85 1829 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu Call for papers - PODC
C02122 00392 ∂02-Nov-85 1158 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ernie.berkeley.edu
C02125 00393 ∂03-Nov-85 1923 LANSKY@SRI-AI.ARPA planlunch reminder -- Monday/11am/David Israel
C02128 00394 ∂03-Nov-85 2051 BARWISE@SU-CSLI.ARPA Visitor
C02130 00395 ∂04-Nov-85 0917 INGRID@SU-CSLI.ARPA Symposia on AI
C02135 00396 ∂04-Nov-85 1002 LIBRARY@SU-SCORE.ARPA Applied Numerical Mathematics--New Journal In Math/CS Library
C02137 00397 ∂04-Nov-85 1036 BARWISE@SU-CSLI.ARPA Talk on semantics of types in computer languages
C02139 00398 ∂04-Nov-85 1140 HOLDEN@SU-CSLI.ARPA Friday afternoon drinking sessions
C02140 00399 ∂04-Nov-85 1229 ACUFF@SUMEX-AIM.ARPA What Explorer files to keep
C02142 00400 ∂04-Nov-85 1250 ACUFF@SUMEX-AIM.ARPA Booting Lisp Machines
C02145 00401 ∂04-Nov-85 1436 ULLMAN@SU-SCORE.ARPA new contract
C02146 00402 ∂04-Nov-85 1546 GINSBERG@SUMEX-AIM.ARPA change to SIGlunch mailing list
C02162 00403 ∂04-Nov-85 1607 ACUFF@SUMEX-AIM.ARPA Symbolics shuffling and installation
C02164 00404 ∂04-Nov-85 1618 SJG change to SIGlunch mailing list
C02165 00405 ∂04-Nov-85 1651 ullman@su-aimvax.arpa more papers received today
C02166 00406 ∂04-Nov-85 1702 ullman@su-aimvax.arpa paper received
C02168 00407 ∂04-Nov-85 1703 REGES@SU-SCORE.ARPA lunch reminder
C02170 00408 ∂04-Nov-85 1720 @SU-SCORE.ARPA:WINOGRAD@SU-CSLI.ARPA Forum speakers
C02174 00409 ∂04-Nov-85 2019 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Talk on semantics of types in computer languages
C02176 00410 ∂04-Nov-85 2048 @SU-CSLI.ARPA:dirk@SU-PSYCH Psychology Department Friday Seminar.
C02181 00411 ∂04-Nov-85 2138 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu POPL 86
C02199 00412 ∂04-Nov-85 2213 @SU-SUSHI.ARPA:broder@decwrl.DEC.COM BATS at DEC - November 22
C02201 00413 ∂05-Nov-85 0046 DAVIES@SUMEX-AIM.ARPA No AAP meeting Wednesday
C02202 00414 ∂05-Nov-85 1148 BERG@SU-SCORE.ARPA technical reports
C02204 00415 ∂05-Nov-85 1438 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
C02209 00416 ∂05-Nov-85 1519 LIBRARY@SU-SCORE.ARPA Socrates: Searching By Call Number In The Technical Reports File
C02211 00417 ∂05-Nov-85 1543 LIBRARY@SU-SCORE.ARPA Socrates: How to Telnet--A Reminder
C02213 00418 ∂05-Nov-85 1551 LIBRARY@SU-SCORE.ARPA Socrates: Telnet message correction
C02214 00419 ∂05-Nov-85 1620 @SU-SCORE.ARPA:EVAN@SU-CSLI.ARPA Re: Socrates: Searching By Call Number In The Technical Reports File
C02216 00420 ∂05-Nov-85 1632 @SU-SCORE.ARPA:EVAN@SU-CSLI.ARPA Last Message (an apology)
C02217 00421 ∂05-Nov-85 1748 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #27
C02230 00422 ∂05-Nov-85 1914 ullman@su-aimvax.arpa meeting tomorrow
C02231 00423 ∂05-Nov-85 2305 ACUFF@SUMEX-AIM.ARPA 3640 setup and ready for use
C02232 00424 ∂06-Nov-85 0631 PATASHNIK@SU-SUSHI.ARPA AFLB abstracts
C02238 00425 ∂06-Nov-85 1409 ullman@su-aimvax.arpa paper received
C02239 00426 ∂06-Nov-85 1742 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH
C02243 00427 ∂06-Nov-85 2010 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu MFCS '86 Call for Papers
C02252 00428 ∂08-Nov-85 1647 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 12 (R. Wilensky, UCB)
C02258 00429 ∂08-Nov-85 1649 @SU-CSLI.ARPA:barwise.pa@Xerox.ARPA "Machines and the mental"
C02260 00430 ∂08-Nov-85 1704 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #28
C02272 00431 ∂08-Nov-85 1826 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu
C02278 00432 ∂08-Nov-85 1829 admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 12 (R. Wilensky, UCB)
C02284 00433 ∂09-Nov-85 0513 VONHENKE@SRI-CSL.ARPA RISKS-1.22
C02321 00434 ∂09-Nov-85 1516 ACUFF@SUMEX-AIM.ARPA More Explorer info
C02323 00435 ∂09-Nov-85 1822 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #29
C02329 00436 ∂10-Nov-85 1804 @SU-SCORE.ARPA:JMC@SU-AI.ARPA
C02330 00437 ∂10-Nov-85 1916 LANSKY@SRI-AI.ARPA PLANLUNCH reminder -- 11AM Moshe Vardi
C02334 00438 ∂11-Nov-85 0140 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #44
C02343 00439 ∂11-Nov-85 0945 NILSSON@SU-SCORE.ARPA New Keys
C02346 00440 ∂11-Nov-85 1043 INGRID@SU-CSLI.ARPA Symposia on AI
C02350 00441 ∂11-Nov-85 1040 NILSSON@SU-SCORE.ARPA More "Keys"
C02352 00442 ∂11-Nov-85 1201 INGRID@SU-CSLI.ARPA HOUSEMATE WANTED
C02354 00443 ∂11-Nov-85 1402 @SU-CSLI.ARPA:VAL@SU-AI.ARPA Non-Monotonic Reasoning Seminar
C02356 00444 ∂11-Nov-85 1455 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #30
C02370 00445 ∂11-Nov-85 1539 CAROL@SU-CSLI.ARPA Demo postponed
C02372 00446 ∂11-Nov-85 1541 TAJNAI@SU-SCORE.ARPA IBM/Forum Party 11/14/85
C02374 00447 ∂11-Nov-85 1644 PATASHNIK@SU-SUSHI.ARPA nonAFLB talk
C02376 00448 ∂11-Nov-85 2307 DAVIES@SUMEX-AIM.ARPA No meeting this week
C02377 00449 ∂12-Nov-85 0812 RICHARDSON@SU-SCORE.ARPA CSD Lunch
C02378 00450 ∂12-Nov-85 0835 EMMA@SU-CSLI.ARPA TINLunch
C02380 00451 ∂12-Nov-85 1117 BERGMAN@SU-SCORE.ARPA RA support
C02382 00452 ∂12-Nov-85 1118 NILSSON@SU-SCORE.ARPA Student Names
C02385 00453 ∂12-Nov-85 1119 NILSSON@SU-SCORE.ARPA SOE Committees
C02388 00454 ∂12-Nov-85 1236 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
C02389 00455 ∂12-Nov-85 1236 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
C02393 00456 ∂12-Nov-85 1237 RICHARDSON@SU-SCORE.ARPA CSD 500 Colloquium Series
C02394 00457 ∂12-Nov-85 1239 NILSSON@SU-SCORE.ARPA Master Keys
C02396 00458 ∂12-Nov-85 1254 ACUFF@SUMEX-AIM.ARPA Explorer 1.0.2: anyone need it?
C02397 00459 ∂12-Nov-85 1346 WASOW@SU-CSLI.ARPA consulting offer
C02399 00460 ∂12-Nov-85 1448 ullman@su-aimvax.arpa paper received
C02400 00461 ∂12-Nov-85 1519 ullman@su-aimvax.arpa tomorrow's meeting
C02401 00462 ∂12-Nov-85 1522 MODICA@SU-SCORE.ARPA info for TV students
C02403 00463 ∂12-Nov-85 1522 MODICA@SU-SCORE.ARPA info for TV students
C02405 00464 ∂12-Nov-85 1519 ullman@su-aimvax.arpa another paper
C02406 00465 ∂12-Nov-85 1747 PAPA@SU-SCORE.ARPA Re: another paper
C02408 00466 ∂12-Nov-85 1818 ullman@su-aimvax.arpa Re: another paper
C02409 00467 ∂13-Nov-85 0612 PATASHNIK@SU-SUSHI.ARPA AFLB abstracts
C02413 00468 ∂13-Nov-85 1026 CAROL@SU-CSLI.ARPA Sketch demo
C02416 00469 ∂13-Nov-85 1040 CAROL@SU-CSLI.ARPA Sketch demo, correction
C02419 00470 ∂13-Nov-85 1141 NILSSON@SU-SCORE.ARPA Herb Grosch
C02420 00471 ∂13-Nov-85 1147 DALRYMPLE@SU-CSLI.ARPA party
C02421 00472 ∂13-Nov-85 1353 ACUFF@SUMEX-AIM.ARPA Bug reports for Explorers
C02423 00473 ∂13-Nov-85 1403 REGES@SU-SCORE.ARPA TAs
C02425 00474 ∂13-Nov-85 1606 NILSSON@SU-SCORE.ARPA Fac. Lunch
C02427 00475 ∂13-Nov-85 1704 @SU-SUSHI.ARPA:broder@decwrl.DEC.COM BATS program
C02430 00476 ∂13-Nov-85 1749 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #31
C02437 00477 ∂13-Nov-85 1758 EMMA@SU-CSLI.ARPA Newsletter November 14, No. 2
C02456 00478 ∂13-Nov-85 1809 @SU-SUSHI.ARPA:broder@decwrl.DEC.COM Driving to Bats
C02460 00479 ∂13-Nov-85 1829 @SU-SCORE.ARPA:coraki!pratt@su-navajo.arpa Herb Grosch
C02462 00480 ∂13-Nov-85 2319 @SU-SCORE.ARPA:coraki!pratt@su-navajo.arpa Fac. Lunch
C02464 00481 ∂14-Nov-85 0002 Operator@SU-SUSHI.ARPA bats at dec, 11/22
C02465 00482 ∂14-Nov-85 0830 EMMA@SU-CSLI.ARPA Newsletter addition
C02467 00483 ∂14-Nov-85 1109 @SU-SCORE.ARPA:guibas@decwrl.DEC.COM Re: info for TV students
C02469 00484 ∂14-Nov-85 1109 @SU-SCORE.ARPA:guibas@decwrl.DEC.COM Re: info for TV students
C02471 00485 ∂14-Nov-85 1343 CAROL@SU-CSLI.ARPA Meet the Author
C02473 00486 ∂14-Nov-85 1405 BSCOTT@SU-SCORE.ARPA Proposals
C02476 00487 ∂14-Nov-85 1434 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH plus other business...
C02482 00488 ∂14-Nov-85 1459 PHILOSOPHY@SU-CSLI.ARPA Colloquium
C02483 00489 ∂14-Nov-85 1515 LANSKY@SRI-AI.ARPA oops!
C02484 00490 ∂14-Nov-85 2006 admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 19 (R. Alterman, UCB)
C02490 00491 ∂14-Nov-85 2017 SF@SU-CSLI.ARPA Talk by Rachel Feferman
C02492 00492 ∂14-Nov-85 2023 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 19 (R. Alterman, UCB)
C02498 00493 ∂14-Nov-85 2045 @SU-SCORE.ARPA:cbosgd!packard!ihesa!olaf@seismo.CSS.GOV
C02501 00494 ∂14-Nov-85 2145 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ernie.berkeley.edu
C02503 00495 ∂15-Nov-85 0734 JF@SU-SUSHI.ARPA bats abstracts
C02504 00496 ∂15-Nov-85 0733 @SU-SUSHI.ARPA:broder@decwrl.DEC.COM Abstracts for BATS talks at DEC
C02511 00497 ∂15-Nov-85 0848 ACUFF@SUMEX-AIM.ARPA Newest batch of Explorers
C02513 00498 ∂15-Nov-85 0848 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #32
C02522 00499 ∂15-Nov-85 0918 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
C02523 00500 ∂15-Nov-85 0921 JJW MJH-LispM news
C02526 00501 ∂16-Nov-85 0750 ullman@su-aimvax.arpa Re: another paper
C02527 00502 ∂16-Nov-85 0751 ark@SALLY.UTEXAS.EDU Re: another paper
C02531 00503 ∂16-Nov-85 0752 maier%oregon-grad.csnet@CSNET-RELAY.ARPA Re: another paper
C02533 00504 ∂16-Nov-85 0757 ACUFF@SUMEX-AIM.ARPA Re: MJH-LispM news
C02534 00505 ∂16-Nov-85 0759 NEALE@SU-CSLI.ARPA
C02536 00506 ∂16-Nov-85 0800 ACUFF@SUMEX-AIM.ARPA KSL-3640-7 down
C02537 00507 ∂16-Nov-85 0759 RICHARDSON@SU-SCORE.ARPA General Faculty Meeting
C02538 00508 ∂16-Nov-85 0801 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #33
C02547 00509 ∂16-Nov-85 0805 PATASHNIK@SU-SUSHI.ARPA Upcoming AFLB canceled
C02548 00510 ∂16-Nov-85 0808 @SU-SCORE.ARPA:ullman@su-aimvax.arpa CS UG program update
C02552 00511 ∂16-Nov-85 1209 BSCOTT@SU-SCORE.ARPA Locks
C02553 00512 ∂17-Nov-85 0623 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #34
C02568 00513 ∂17-Nov-85 1850 ullman@su-aimvax.arpa Re: another paper
C02570 00514 ∂17-Nov-85 1851 LANSKY@SRI-AI.ARPA PLANLUNCH reminder -- Jeff Finger, 11am
C02575 00515 ∂17-Nov-85 1858 BRESNAN@SU-CSLI.ARPA Morphology, Syntax, Discourse Interactions
C02579 00516 ∂17-Nov-85 1859 ACUFF@SUMEX-AIM.ARPA Bug Reporting from Explorers
C02581 00517 ∂18-Nov-85 1012 WECHSLER@SU-CSLI.ARPA XenoneX
C02583 00518 ∂18-Nov-85 1018 INGRID@SU-CSLI.ARPA Symposium on AI
C02587 00519 ∂19-Nov-85 0827 @SU-SUSHI.ARPA:RUTENBURG@SU-SCORE.ARPA ICALP
C02588 00520 ∂19-Nov-85 0843 @SU-CSLI.ARPA:BrianSmith.pa@Xerox.ARPA A day's mail lost
C02590 00521 ∂19-Nov-85 0845 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #35
C02613 00522 ∂19-Nov-85 0852 cheriton@su-pescadero.ARPA Re: another paper
C02615 00523 ∂19-Nov-85 0856 @SU-CSLI.ARPA:CLT@SU-AI.ARPA PALMS
C02616 00524 ∂19-Nov-85 0925 RICHARDSON@SU-SCORE.ARPA Tuesday CSD Lunch
C02617 00525 ∂19-Nov-85 0938 ullman@su-aimvax.arpa meeting
C02618 00526 ∂19-Nov-85 0939 LIBRARY@SU-SCORE.ARPA Socrates: Additional Terminal In Math/CS Library
C02620 00527 ∂19-Nov-85 0944 NILSSON@SU-SCORE.ARPA Visiting Professorship
C02623 00528 ∂19-Nov-85 0945 NEUMANN@SRI-CSL.ARPA RISKS-1.23
C02650 00529 ∂19-Nov-85 1014 DAVIES@SUMEX-AIM.ARPA No meeting tomorrow, November 20
C02651 00530 ∂19-Nov-85 1014 CAROL@SU-CSLI.ARPA Sketch demo
C02653 00531 ∂19-Nov-85 1013 LIBRARY@SU-SCORE.ARPA Math/CS Library: New Books--CS
C02655 00532 ∂19-Nov-85 1140 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar in Logic and Foundations
C02657 00533 ∂19-Nov-85 1145 JF@SU-SUSHI.ARPA p.s. on BATS 11/22/85
C02658 00534 ∂19-Nov-85 1146 JF@SU-SUSHI.ARPA bats headcount
C02659 00535 ∂19-Nov-85 1243 @SU-CSLI.ARPA:CLT@SU-AI.ARPA course description
C02664 00536 ∂19-Nov-85 1315 EMMA@SU-CSLI.ARPA Newsletter
C02665 00537 ∂19-Nov-85 1337 ACUFF@SUMEX-AIM.ARPA Explorer Hardware Watch
C02667 00538 ∂19-Nov-85 1618 RICHARDSON@SU-SCORE.ARPA Faculty Accomplishments
C02673 00539 ∂19-Nov-85 2039 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #36
C02698 00540 ∂20-Nov-85 1153 RICE@SUMEX-AIM.ARPA 36xx -> Explorer Status.
C02704 00541 ∂20-Nov-85 1158 PATASHNIK@SU-SUSHI.ARPA Next AFLB
C02706 00542 ∂20-Nov-85 1205 NEUMANN@SRI-CSL.ARPA RISKS-1.24
C02735 00543 ∂20-Nov-85 1205 LIBRARY@SU-SCORE.ARPA Socrates: Update On Searching Math/CS Technical Reports By Call Numbers (Accession Numbers)
C02738 00544 ∂20-Nov-85 1238 YAMARONE@SU-CSLI.ARPA HUNGRY? X-TRA SANDWICHES AVAILABLE
C02739 00545 ∂20-Nov-85 1407 @SU-SUSHI.ARPA:PAPA@SU-SCORE.ARPA Talk by Victor Klee
C02741 00546 ∂20-Nov-85 1502 @SU-SUSHI.ARPA:PAPA@SU-SCORE.ARPA V. Klee's talk
C02742 00547 ∂20-Nov-85 1506 YAMARONE@SU-CSLI.ARPA HUNGRY?? TURKEY & AVO AVAILABLE
C02744 00548 ∂20-Nov-85 1604 @SU-SUSHI.ARPA:SILVERBERG@SU-SCORE.ARPA Talk by Victor Klee
C02745 00549 ∂20-Nov-85 1814 EMMA@SU-CSLI.ARPA Newsletter November 21, No. 3
C02768 00550 ∂21-Nov-85 0933 EMMA@SU-CSLI.ARPA Newsletter addition
C02769 00551 ∂21-Nov-85 1100 @SU-SCORE.ARPA:ullman@su-aimvax.arpa International CS Institute
C02773 00552 ∂21-Nov-85 1134 RICE@SUMEX-AIM.ARPA 3600 -> Explorer Update.
C02774 00553 ∂21-Nov-85 1258 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #37
C02798 00554 ∂21-Nov-85 1525 @MIT-MC.ARPA:JCMA@MIT-MC.ARPA Classic Quotes (Positivism Assesses Progress in Meaning)
C02800 00555 ∂21-Nov-85 1541 @MIT-MC.ARPA:JCMA@MIT-MC.ARPA Classic Quotes (Positivism Assesses Progress in Meaning)
C02802 00556 ∂21-Nov-85 1639 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH -- Haim Gaifman
C02809 00557 ∂21-Nov-85 1704 ullman@su-aimvax.arpa paper recieved
C02810 00558 ∂21-Nov-85 1721 ullman@su-aimvax.arpa vowel fans take note
C02811 00559 ∂21-Nov-85 1754 WINOGRAD@SU-CSLI.ARPA No ENVIRONMENTS meeting until Dec 9
C02813 00560 ∂21-Nov-85 2104 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu ADVANCED COURSE ON PETRI NETS
C02819 00561 ∂22-Nov-85 1248 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #38
C02851 00562 ∂22-Nov-85 1455 @MIT-MC.ARPA:MERRY.pa@XEROX.ARPA Re: Classic Quotes (Positivism Assesses Progress in Meaning)
C02853 00563 ∂22-Nov-85 1902 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu Call for Algorithms Papers
C02856 00564 ∂22-Nov-85 1941 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
C02859 00565 ∂23-Nov-85 0351 admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 26 (E. Clark, Stanford)
C02864 00566 ∂23-Nov-85 0352 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 26 (E. Clark, Stanford)
C02869 00567 ∂23-Nov-85 1159 ACUFF@SUMEX-AIM.ARPA 3674 and 3647 status
C02871 00568 ∂23-Nov-85 1233 ACUFF@SUMEX-AIM.ARPA Air Conditioning in the Welch Road Machine Room
C02874 00569 ∂23-Nov-85 1255 JOHNSON@SU-CSLI.ARPA Intro to Computational Linguistics
C02876 00570 ∂24-Nov-85 1238 LANSKY@SRI-AI.ARPA tomorrow's planlunch -- 11AM
C02878 00571 ∂25-Nov-85 0924 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
C02879 00572 ∂25-Nov-85 1405 BERG@SU-SCORE.ARPA evaluation forms
C02881 00573 ∂25-Nov-85 1600 EMMA@SU-CSLI.ARPA The Next TINLunch
C02884 00574 ∂25-Nov-85 1920 ZEC@SU-CSLI.ARPA linguistcs department colloquium
C02886 00575 ∂26-Nov-85 0745 @SU-SUSHI.ARPA:karp@ernie.berkeley.edu
C02888 00576 ∂26-Nov-85 0953 YAMARONE@SU-CSLI.ARPA NO LUNCH WEDNESDAY
C02889 00577 ∂26-Nov-85 1012 RICHARDSON@SU-SCORE.ARPA CSD Lunch
C02890 00578 ∂26-Nov-85 1050 ullman@su-aimvax.arpa meeting tomorrow
C02891 00579 ∂26-Nov-85 1435 MODICA@SU-SCORE.ARPA Grades
C02894 00580 ∂26-Nov-85 2228 BRESNAN@SU-CSLI.ARPA interactions of morphology, syntax, and discourse
C02899 00581 ∂27-Nov-85 0015 EMMA@SU-CSLI.ARPA Ventura Security
C02900 00582 ∂27-Nov-85 0842 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #39
C02911 00583 ∂27-Nov-85 1056 ACUFF@SUMEX-AIM.ARPA Patches for Some Explorer Bugs
C02913 00584 ∂27-Nov-85 1411 ullman@su-aimvax.arpa algebra of derivations
C02915 00585 ∂27-Nov-85 1446 SCHOLZ@SU-SUSHI.ARPA meeting of the minds
C02917 00586 ∂27-Nov-85 1648 LANSKY@SRI-AI.ARPA future plans for PLANLUNCH
C02919 00587 ∂27-Nov-85 1708 BSCOTT@SU-SCORE.ARPA Tuesday Faculty Lunch
C02921 00588 ∂28-Nov-85 1917 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #40
C02952 00589 ∂29-Nov-85 0848 NILSSON@SU-SCORE.ARPA Computing Needs
C02955 00590 ∂29-Nov-85 1028 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books--CS
C02957 00591 ∂29-Nov-85 1527 NILSSON@SU-SCORE.ARPA Patent agreement
C02958 00592 ∂29-Nov-85 1537 LIBRARY@SU-SCORE.ARPA Paper Index To Technical Reports No Longer Available
C02960 00593 ∂01-Dec-85 1235 JOHNSON@SU-CSLI.ARPA My books..
C02961 00594 ∂01-Dec-85 1639 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #41
C02988 00595 ∂01-Dec-85 2336 ACUFF@SUMEX-AIM.ARPA New Explorer Software
C02991 00596 ∂01-Dec-85 2347 ACUFF@SUMEX-AIM.ARPA Compatibility between Symbolics 36xx and TI Explorer
C02993 00597 ∂02-Dec-85 0859 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
C02994 00598 ∂02-Dec-85 0947 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Dec. 3, 1985
C03001 00599 ∂02-Dec-85 0947 admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Dec. 3, 1985
C03008 00600 ∂02-Dec-85 1002 BSCOTT@SU-SCORE.ARPA Tuesday Lunch
C03009 00601 ∂02-Dec-85 1015 ZEC@SU-CSLI.ARPA interactions of morphology, syntax, and discurse
C03010 00602 ∂02-Dec-85 1041 BSCOTT@SU-SCORE.ARPA RFP from IBM
C03013 00603 ∂02-Dec-85 1106 RICHARDSON@SU-SCORE.ARPA Faculty Accomplishments
C03014 00604 ∂02-Dec-85 1121 EMMA@SU-CSLI.ARPA Bibtex emacs library
C03016 00605 ∂02-Dec-85 1121 REGES@SU-SCORE.ARPA anyone free on 11/5?
C03018 00606 ∂02-Dec-85 1123 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Announcing a Logic Meeting at UCLA
C03023 00607 ∂02-Dec-85 1205 EMMA@SU-CSLI.ARPA bibtex emacs library
C03024 00608 ∂02-Dec-85 1620 RICHARDSON@SU-SCORE.ARPA Near West Campus Invitation
C03026 00609 ∂02-Dec-85 1716 DAVIES@SUMEX-AIM.ARPA No meeting this Wednesday
C03027 00610 ∂02-Dec-85 1727 MODICA@SU-SCORE.ARPA survey forms
C03028 00611 ∂02-Dec-85 1732 MODICA@SU-SCORE.ARPA grades
C03029 00612 ∂02-Dec-85 1802 TAJNAI@SU-SCORE.ARPA Bell Fellowship
C03031 00613 ∂03-Dec-85 0923 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar in Logic and Foundations
C03033 00614 ∂03-Dec-85 0923 ullman@su-aimvax.arpa CS300 talk
C03034 00615 ∂03-Dec-85 1101 TAJNAI@SU-SCORE.ARPA Bell Fellowship
C03035 00616 ∂03-Dec-85 1148 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH
C03039 00617 ∂03-Dec-85 1203 NILSSON@SU-SCORE.ARPA Faculty Meeting
C03043 00618 ∂03-Dec-85 1315 MODICA@SU-SCORE.ARPA End Quarter Reports
C03044 00619 ∂03-Dec-85 1915 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #42
C03072 00620 ∂03-Dec-85 1934 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #42
C03100 00621 ∂03-Dec-85 2038 BRESNAN@SU-CSLI.ARPA interactions of morphology, syntax, and discourse
C03105 00622 ∂04-Dec-85 0735 PATASHNIK@SU-SUSHI.ARPA next AFLBs
C03110 00623 ∂04-Dec-85 0919 ullman@su-aimvax.arpa meeting
C03111 00624 ∂04-Dec-85 0949 @SU-SCORE.ARPA:MCCALL@SU-SUSHI.ARPA Announcing: CS523 - Survey of Artificial Intelligence
C03117 00625 ∂04-Dec-85 1037 DALRYMPLE@SU-CSLI.ARPA fun on Friday
C03118 00626 ∂04-Dec-85 1320 MODICA@SU-SCORE.ARPA Grade Sheets
C03120 00627 ∂04-Dec-85 1341 CAROL@SU-CSLI.ARPA Parking man
C03121 00628 ∂04-Dec-85 1702 EMMA@SU-CSLI.ARPA Newsletter December 5, No. 4
C03137 00629 ∂04-Dec-85 2141 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu Call for papers - Logic and Applications
C03142 00630 ∂05-Dec-85 0733 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #43
C03146 00631 ∂05-Dec-85 0958 REULING@SU-SCORE.ARPA CSD Mailing Lists
C03148 00632 ∂05-Dec-85 1223 EMMA@SU-CSLI.ARPA Newsletter correction
C03155 00633 ∂05-Dec-85 1339 @SU-SCORE.ARPA:LES@SU-AI.ARPA Facilities action items
C03171 00634 ∂05-Dec-85 1402 TAJNAI@SU-SCORE.ARPA nominations for IBM fellowship
C03173 00635 ∂05-Dec-85 1514 NILSSON@SU-SCORE.ARPA Awards
C03176 00636 ∂05-Dec-85 1718 ACUFF@SUMEX-AIM.ARPA I'll be gone for 6 days
C03178 00637 ∂05-Dec-85 2102 BRESNAN@SU-CSLI.ARPA morphology/syntax/discourse interactions
C03181 00638 ∂05-Dec-85 2158 JF@SU-SUSHI.ARPA help
C03182 00639 ∂05-Dec-85 2247 CAROL@SU-CSLI.ARPA New office
C03184 00640 ∂06-Dec-85 1003 CONTRERAS@SU-SCORE.ARPA Package
C03185 00641 ∂06-Dec-85 1300 YAMARONE@SU-CSLI.ARPA HOLIDAY PARTY NEXT FRIDAY(THE 13TH!)
C03192 00642 ∂06-Dec-85 1309 YAMARONE@SU-CSLI.ARPA WHAT TIME'S THE PARTY BEGIN?
C03194 00643 ∂06-Dec-85 1408 RICE@SUMEX-AIM.ARPA Explorers have new MIBs
C03195 00644 ∂06-Dec-85 1423 @SU-CSLI.ARPA:PCOHEN@SRI-AI.ARPA Seminar by N. S. Sridharan, BBN Labs
C03199 00645 ∂06-Dec-85 1629 @SU-CSLI.ARPA:PCOHEN@SRI-AI.ARPA time for seminar by N. S. Sridharan
C03200 00646 ∂06-Dec-85 1634 PHILOSOPHY@SU-CSLI.ARPA colloquium
C03202 00647 ∂06-Dec-85 2050 @SU-SUSHI.ARPA:karp@ernie.berkeley.edu
C03204 00648 ∂07-Dec-85 0846 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #44
C03215 00649 ∂08-Dec-85 2355 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #45
C03219 00650 ∂09-Dec-85 1032 RICHARDSON@SU-SCORE.ARPA General Faculty Meeting
C03222 00651 ∂09-Dec-85 1045 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
C03223 00652 ∂09-Dec-85 1333 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books--CS
C03225 00653 ∂09-Dec-85 1720 @SU-CSLI.ARPA:WALDINGER@SRI-AI.ARPA seminar on program transformation wednes, 3:45
C03227 00654 ∂09-Dec-85 2250 DAVIES@SUMEX-AIM.ARPA AAP meeting Wednesday
C03228 00655 ∂10-Dec-85 1029 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
C03229 00656 ∂10-Dec-85 1214 RICHARDSON@SU-SCORE.ARPA CSD 500 Colloquium Series
C03232 00657 ∂10-Dec-85 1235 DAVIES@SUMEX-AIM.ARPA Wednesday AAP meeting 9:30
C03233 00658 ∂10-Dec-85 1237 BROWN@SU-CSLI.ARPA Message for Sandwich
C03234 00659 ∂10-Dec-85 1319 LIBRARY@SU-SCORE.ARPA The Connection Machine by Hillis
C03236 00660 ∂10-Dec-85 1834 ullman@su-aimvax.arpa tomorrow's meeting
C03238 00661 ∂10-Dec-85 2226 vardi@su-aimvax.arpa Database Seminar
C03241 00662 ∂11-Dec-85 0617 PATASHNIK@SU-SUSHI.ARPA Last AFLB of the quarter
C03246 00663 ∂11-Dec-85 1424 RICE@SUMEX-AIM.ARPA Today's talk.
C03247 00664 ∂11-Dec-85 1436 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu Technical Debate at Stanford on SDI, December 19
C03251 00665 ∂11-Dec-85 1752 EMMA@SU-CSLI.ARPA Newsletter December 12, No. 5
C03268 00666 ∂12-Dec-85 0902 LIBRARY@SU-SCORE.ARPA USENIX and UNIFORUM Conference Proceedings
C03270 00667 ∂12-Dec-85 0943 YAMARONE@SU-CSLI.ARPA HOLIDAY CELEBRATION REMINDER
C03277 00668 ∂12-Dec-85 1116 GOTELLI@SU-SCORE.ARPA Correction
C03278 00669 ∂12-Dec-85 1136 GOTELLI@SU-SCORE.ARPA New Staff Member
C03280 00670 ∂12-Dec-85 1238 ullman@su-aimvax.arpa Recent developments
C03290 00671 ∂12-Dec-85 1537 ullman@su-aimvax.arpa oops
C03294 00672 ∂13-Dec-85 0843 TAJNAI@SU-SCORE.ARPA Contacts at Apple
C03295 00673 ∂13-Dec-85 0936 MODICA@SU-SCORE.ARPA End Quarter Reports
C03297 00674 ∂13-Dec-85 1019 MODICA@SU-SCORE.ARPA important correctio
C03298 00675 ∂13-Dec-85 1141 ullman@su-aimvax.arpa oops again
C03300 00676 ∂13-Dec-85 1422 ullman@su-aimvax.arpa papers received
C03301 00677 ∂13-Dec-85 1441 LANSKY@SRI-AI.ARPA revised PLANLUNCH schedule
C03303 00678 ∂13-Dec-85 1609 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ernie.berkeley.edu
C03305 00679 ∂13-Dec-85 1804 @MIT-MC.ARPA:JF@SU-SUSHI.ARPA SDI Debate at Stanford, 12/19/85
C03309 00680 ∂14-Dec-85 JF@SU-SUSHI.ARPA 14-Dec-85 JMC Sleator talk at SRC, Monday, 12/16/85, 2 p.m.
C03312 ENDMK
C⊗;
∂06-Aug-85 0931 NISSENBAUM@SU-CSLI.ARPA CSLI Talk
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 09:31:27 PDT
Date: Tue 6 Aug 85 09:29:27-PDT
From: Helen Nissenbaum <NISSENBAUM@SU-CSLI.ARPA>
Subject: CSLI Talk
To: folks@SU-CSLI.ARPA
Reminder about today's CSLI talk:
time: 4 p.m.
place: Ventura Seminar Room
Aaron Sloman
"The Processing of Motives in Artificial Systems"
-------
∂06-Aug-85 1056 TRUDY@SU-CSLI.ARPA Julia Robinson
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 10:56:06 PDT
Date: Tue 6 Aug 85 10:57:35-PDT
From: Trudy Vizmanos <TRUDY@SU-CSLI.ARPA>
Subject: Julia Robinson
To: Researchers@SU-CSLI.ARPA
TEL: 497-1839
Julia Robinson died this morning, at the age of 66, after a protracted and courageous struggle with leukemia. On Friday she went into a coma, from which she never recovered.
Professor Robinson is widely known for her outstanding work i
mathematical logic, especially the theory of recursive functions. She
contributed in essential ways to the attack on Hilbert's 10th problem
regarding the question of effective decidability of Diophantine equations;
this led eventually to the negative solution by Yuri Mathijasevitch.
Professor of Mathematics at the University of California, Berkeley,
Julia Robinson was also President of the American Mathematical Society
for 1983 and 1984, a member of the National Academy of Sciences since
1976, and a MacArthur Foundation Fellow since 1983. Through her professional
positions and by her personal example and encouragement, she fostered work
of the highest quality in mathematics. Liked and admired by all who knew
her, she will be greatly missed. She is survived by her husband,
Raphael M. Robinson, and her sister, Constance Reid.
I am informed that Julia Robinson asked that there be no funeral
services and that those wishing to do something in her memory, should
send a contribution to the Alfred Tarski Fund at the Department of
Mathematics, U.C. Berkeley. Professor Robinson was instrumental
in helping set us this fund, which will be used to sponsor visitors and
lectures on logic and the foundations of mathematics in Berkeley. May
I suggest that her name be mentioned when making a contribution.
Solomon Feferman
-------
∂06-Aug-85 1102 TRUDY@SU-CSLI.ARPA Julia Robinson
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 11:01:46 PDT
Date: Tue 6 Aug 85 11:03:21-PDT
From: Trudy Vizmanos <TRUDY@SU-CSLI.ARPA>
Subject: Julia Robinson
To: Researchers@SU-CSLI.ARPA
TEL: 497-1839
Sorry, the actual death of Julia Robinson was July 30, 1985.
*trudy
-------
∂06-Aug-85 1316 EMMA@SU-CSLI.ARPA Newsletter
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 13:16:02 PDT
Date: Tue 6 Aug 85 13:14:29-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter
To: folks@SU-CSLI.ARPA
Tel: 497-3479
I am likely to be quite busy tomorrow, so please mail all items
for the newsletter as early as possible.
Remember that people draw quite extensively from the newsletter when
writing the year end report.
Emma
Ex nihilo nihil fit
-------
∂06-Aug-85 1702 SBARNES@SUMEX-AIM.ARPA SIGLUNCH Friday August 9, 1985
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 17:02:46 PDT
Date: Tue 6 Aug 85 16:07:30-PDT
From: Carol Wright/Susie Barnes <SBARNES@SUMEX-AIM.ARPA>
Subject: SIGLUNCH Friday August 9, 1985
To: siglunch@SUMEX-AIM.ARPA
Message-ID: <12133063338.65.SBARNES@SUMEX-AIM.ARPA>
SIGLUNCH
DATE: Friday, August 9, 1985
LOCATION: Chemistry Gazebo, betweeen Physical and
Organic Chemistry
TIME: 12:05
SPEAKER: Peter Jackson,
Department of Artificial Intelligence,
University of Edinburgh
TITLE: A Flexible Toolkit for Building Expert Systems.
This presentation describes the progress to date of a three-year
Alvey-funded project to study, design and implement tools for building
knowledge-based systems. The parties involved are Edinburgh University's
Department of Artificial Intelligence and GEC's Artificial Intelligence
Group at Great Baddow. The aim of the seminar is not to present finished
work (the project is only six months old!), but rather to air our ideas and
prejudices in the hope of attracting criticism and other kinds of feedback
from the expert systems community.
Our survey of current expert systems technology has led us to believe that
neither shells such as EMYCIN (and derivatives) nor high-level programming
languages (such as LOOPS) represent the last word in expert system building
tools. The former are generally restrictive with respect to both the
representation of knowledge and the specification of control, while the
latter present the average programmer with a bewildering array of
possibilities with little indication of how one combines different
programming styles in the construction of an expert systems architecture.
Thus, although there are groups of users for whom shells and AI programming
languages are well-suited, we feel that there is a substantial gap in the
market between the relative beginner or non-programmer, for whom the
majority of commercial shells are intended, and the veteran hacker, for and
by whom systems like LOOPS were developed.
The alternative approach that we are currently exploring can be summed up by
a number of slogans:
(1) The process of choosing a logically adequate representation language and
a heuristically adequate control regime and embedding these into a suitable
architecture should be guided by some analysis of the task one wants one's
system to perform.
(2) It is worth attempting to establish a correlation between a taxonomy of
expert systems tasks and representational schemes based on logical
languages, with respect to both the expressiveness required by the task
(e.g. modal and temporal notions, fuzziness, etc) and the control of
inference (e.g. different problem solving strategies).
(3) It is worth attempting to establish a similar correlation between tasks
and problem solving paradigms (such as ends-means analysis, hypothesize and
test, etc), with a view to helping the user decide on an architecture within
which he can embed the interpretation of this chosen logical language.
The problems we are currently considering include the following:
(1) Is it possible to provide, along with the toolkit, an abstract
architecture that can be instantiated in different ways to implement
different problem solving paradigms?
(2) Could one then embed different interpretations of different logics in
this architecture as part of the instantiation process?
(3) Could one get the behaviour associated with different problem solving
paradigms from this instantiated architecture by running the logical
language under different meta-level regimes?
(4) Will knowledge bases created for use with one instantiation of the
architecture have to be 'recompiled' for use with another instantiation?
(5) How can we help a user to make the 'right' design decisions (assuming we
know what these are)?
We feel that this research program raises a number of very difficult issues,
many of which will not be solved within the scope of the present project.
Nevertheless, we also feel that practical advances in expert systems
development ultimately depend upon theoretical issues of this kind being
addressed, however inadequately. We still have open minds with regard to
the kinds of utility that a toolkit should provide, and are always ready to
talk to both the builders and users of tools in order to try and gain new
insights into the problem.
-------
∂06-Aug-85 1831 DAVIES@SUMEX-AIM.ARPA No meeting this week
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 18:31:07 PDT
Date: Tue, 6 Aug 1985 16:44 PDT
Message-ID: <DAVIES.12133070105.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: No meeting this week
cc: Davies@SUMEX-AIM.ARPA
There will be no Advanced Architectures Project meeting this week.
-- Byron
∂06-Aug-85 1900 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #9
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 18:59:52 PDT
Date: 6 Aug 85 1912-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #9
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Tuesday, 6 Aug 1985 Volume 1 : Issue 9
Today's Topics:
Symbolic Computing = Computing
First PARSYM Survey
----------------------------------------------------------------------
Date: Fri, 2 Aug 85 22:18:42 pdt
From: coraki!pratt@Navajo (Vaughan Pratt)
Subject: Re: PARSYM Digest V1 #8
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Symbolic and numerical computing
ALL computing applications are symbolic.
My position exactly. I particularly appreciated GLS's algebraic
examples, which I thought were right on. Subject closed (as far
as I'm concerned).
-v
------------------------------
Date: Tuesday, 6 August 1985, 5:15 pm PDT
From: Davies@SUMEX
Subject: Symbolic Computing
The cat is out of the bag. Symbolic computing is indeed all
computing. PARSYM was designated the netwide mailing list for
*symbolic* computing in order to broaden the domain of discourse
rather than to restrict it to any particular branch of computing. I
hope it won't be long before someone will ask the analogous question
about parallel computing -- and get the *same* answer.
-- Your moderator
------------------------------
Date: Tuesday, 6 August 1985, 5:30 pm PDT
From: Davies@SUMEX
Subject: The First PARSYM Survey
As a field of study, parallel computing is nearly as old as computing
itself. Nonetheless, it is clear that a major shift has recently
occurred in both the academic and industrial communities: parallel
computing is now hot stuff.
In this, the first PARSYM survey, I would like to uncover some of the
motivations for this surge towards parallelism, by asking the
readership the following few questions. I'll compile the answers and
report back to the mailing list.
1. What, if any, is your target application for parallel computing?
(Theoreticians aren't required to reply to this question.)
2. Is performance improvement your main goal in exploring parallel
computing?
3. (a) If so, what degree of performance improvement does your target
application require (in, say, orders of magnitude)? What
degree of performance improvement does your current approach
promise?
(b) If not, what else do you expect to achieve through the use of
parallelism?
To respond to the survey, fill in the following form and return it to:
PARSYM-Survey@SUMEX-AIM.ARPA
(not to PARSYM or PARSYM-Request, please).
-- First PARSYM Survey --
1. Target application:
2. Is performance your main goal? (Yes/No)
3. (a) If so, (i) required performance improvement:
(ii) expected performance improvement:
(b) Other goals for parallelism:
End of PARSYM Digest
********************
∂07-Aug-85 1133 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA NEXT MONDAY'S PLANLUNCH
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 7 Aug 85 11:33:05 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Wed 7 Aug 85 11:30:25-PDT
Date: Wed 7 Aug 85 11:26:38-PDT
From: LANSKY@SRI-AI.ARPA
Subject: NEXT MONDAY'S PLANLUNCH
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, rsimmons@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
vanLehn@XEROX.ARPA, araya@XEROX.ARPA, frayman@XEROX.ARPA,
suchman@XEROX.ARPA, weld@XEROX.ARPA, mittal@XEROX.ARPA, dekleer@XEROX.ARPA
Experiments with Belief Resolution
Kurt Konolige and Christophe Geissler
SRI AI Center
11:00 AM, Monday, August 12
SRI International, Building E, Room EJ232
In recent work, Konolige developed a resolution rule for a quantified
modal logic of belief. However, the rule is difficult to apply in
practice, because it takes an arbitrary number of input clauses, and
some instances of the rule may subsume others. In this talk we
describe a solution to this problem based on a generalization of
semantic attachment, that controls the growth of the search space. We
have implemented the resulting version of belief resolution with
Stickel's first-order connection-graph theorem prover. We present
several examples of automatic reasoning about belief using this
system, including a solution to the wise man problem.
-------
∂07-Aug-85 1532 ullman@diablo paper received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 7 Aug 85 15:32:01 PDT
Date: Wed, 7 Aug 85 15:24:00 pdt
From: Jeff Ullman <ullman@diablo>
Subject: paper received
To: nail@diablo
Would anybody like a draft of "Earley Deduction," by Harry Porter,
a student of Dave Maier? It talks about the "LR(k)" style of
deduction that Moshe discussed not so long ago (but the idea
apparently dates back to 1983 at least, maybe "earlier").
I wonder whether one can use this algorithm to lower bound the
number of deductions made by any of the other algorithms
we've been talking about.
∂07-Aug-85 1718 EMMA@SU-CSLI.ARPA Newsletter August 8, No. 40
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 7 Aug 85 17:18:14 PDT
Date: Wed 7 Aug 85 16:44:32-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter August 8, No. 40
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
August 8, 1985 Stanford Vol. 2, No. 40
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, August 15, 1985
12 noon TINLunch
Ventura Hall No Lunch this week
Conference Room
2:15 p.m. CSLI Talk
Ventura Hall ``Relevant Arithmetic and Automatic Theorem Proving''
Conference Room Bob Meyer, Australian National University
(Abstract next week)
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
ANNOUNCEMENT
No activities take place today.
←←←←←←←←←←←←
CSLI TALK
On Situation Semantics
Robin Cooper, University of Wisconsin
Ventura Conference Room, August 14, 2 p.m.
←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
Summary of the meeting on Thursday, August 1
Sells, Zaenen, and Zec continued their presentation on a typology
of reflexive constructions, focussing on the interpretation assigned
to structures containing reflexive pronouns. In particular, they
argued that the traditional conception of the ``bound variable'' vs.
``coreferential'' distinction is not fine-grained enough and
introduced a third interpretation, called ``discourse binding''; this
builds on the account of anaphora developed in Sells' paper
``Restrictive and Non-Restrictive Modification'' (CSLI Report No. 28).
With regard to the interpretation of reflexive constructions,
languages fall into two classes:
--Those that only allow the bound variable interpretation.
--Those that allow either the bound variable interpretation or the
discourse binding interpretation.
A notational system was presented for representing these
interpretations, using the basics of Kamp's Discourse Representation
Theory, and rules for constructing such representations from syntactic
structures were discussed.
Finally, some speculations were advanced as to the nature of the
interpretations of other constructions involving reflexives, in
particular the mediopassive and inchoative use of the `-yi-' reflexive
in Kungparlang. --Peter Sells
!
Page 2 CSLI Newsletter August 8, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
PIXELS AND PREDICATES: AREA P1
``Diagram Understanding:
The Intersection of Computer Graphics and Computer Vision''
Fanya S. Montalvo, MIT, Artificial Intelligence Laboratory
Summary of the meeting on August 7
A problem common to computer vision and computer graphics was
identified. It deals with the representation, acquisition, and
validation of symbolic descriptions for visual properties. The
utility of treating this area as one was explained in terms of
providing the facility for diagrammatic conversations with systems. I
call this area ``diagram understanding'', which is analogous to
natural language understanding. The recognition and generation of
visual objects are two sides of the same symbolic coin. A paradigm
for the discovery of higher-level visual properties was introduced,
and its application to computer vision and computer graphics
described. The notion of denotation was introduced in this context.
It is the map between linguistic symbols and visual properties. A
method was outlined for associating symbolic descriptions with visual
properties in such a way that human subjects can be brought into the
loop in order to validate (or specify) the denotation map. Secondly,
a way of discovering a natural set of visual primitives was
introduced. --Fanya Montalvo
←←←←←←←←←←←←
SUMMARY OF NL2 TALK
``Some Null Subject Constructions in Modern Irish''
Jim McCloskey, University College Dublin
Tuesday, July 23, 1:00
The paper discusses a group of related constructions in Modern
Irish which have two characteristics in common. They have subjects
which are phonologically null and which are pleonastic. The paper is
particularly concerned with the interaction between unaccusatives and
a passive construction.
←←←←←←←←←←←←
NEW CSLI REPORT
Report No. CSLI-85-28, ``Restrictive and Non-restrictive
Modification'' by Peter Sells, has just been published. This report
may be obtained by writing to David Brown, CSLI, Ventura Hall,
Stanford, CA 94305 or Brown@su-csli.
-------
∂08-Aug-85 1244 YAMARONE@SU-CSLI.ARPA SANDWICH ORDERS <9:30
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 8 Aug 85 12:44:19 PDT
Date: Thu 8 Aug 85 12:43:20-PDT
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: SANDWICH ORDERS <9:30
To: folks@SU-CSLI.ARPA
THE VENTURA SANDWICH CORP. IS GOING TO ATTEMPT A PSYCHOLOGICAL
MANEUVER TO AVOID LATE SANDWICH ORDERS.
FROM NOW ON , SANDWICH ORDERS MUST BE IN BY 9:30 AM THE DAY
OF PURCHASE.. ORDERING THE DAY BEFORE IS ENCOURAGED IF YOU'RE
NOT A MORNING TYPE.. AND REMINDERS WILL BE SENT TO THOSE ORDERING
AFTER 9:30.
SO, ORDER BEFORE 9:30 AND YOU'LL ALL
KNOW VICTUAL SATISFACTION!!!!
YOURS IN LUNCH,
THE VENTURA SANDWICH CORP.
-------
∂08-Aug-85 1320 SELLS@SU-CSLI.ARPA using Imprint
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 8 Aug 85 13:20:17 PDT
Date: Thu 8 Aug 85 13:17:43-PDT
From: Peter Sells <Sells@SU-CSLI.ARPA>
Subject: using Imprint
To: folks@SU-CSLI.ARPA
cc: bboard@SU-CSLI.ARPA
Several people seem to be experiencing difficulty with the new Canon
software. The Imprint command no longer works with .dvi files created by
TeX and LaTeX. To Imprint these, you must run the .dvi files through
Makimp, i.e., you do:
@makimp foo.dvi
This gives you an .imp file which you can Imprint. However, the pages will
reverse; to turn the reversal off you do:
@imprint foo.imp/REVERSE:NO
Maybe this will alleviate some of the problems.
Peter
-------
∂08-Aug-85 1527 PIERRE@SU-CSLI.ARPA Printing DVI files
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 8 Aug 85 15:26:55 PDT
Date: Thu 8 Aug 85 15:25:17-PDT
From: Peter King <PIERRE@SU-CSLI.ARPA>
Subject: Printing DVI files
To: folks@SU-CSLI.ARPA
cc: bboard@SU-CSLI.ARPA, summer@SU-CSLI.ARPA
We hope to reinstate automagic printing of DVI files soon. As you
know, we have switched over to a new brand of Canon software and
things are a little rough around the edges.
Peter
-------
∂09-Aug-85 0944 BETSY@SU-CSLI.ARPA SDF Visit
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 9 Aug 85 09:44:28 PDT
Date: Fri 9 Aug 85 09:40:46-PDT
From: Betsy Macken <BETSY@SU-CSLI.ARPA>
Subject: SDF Visit
To: folks@SU-CSLI.ARPA
The Board of Trustees of the System Development Foundation is making a
site visit on Monday morning (August 12). They will be hearing
presentations, and would like a brief tour of the facilities during
their break (probably around 10:15 or 10:30). They have expressed an
interest in visiting informally with any of you who are around during
the tour.
The members of the Board who will be here are:
Arnold Beckman, Chairman
Chairman, Beckman Instruments, Inc.
Ralph Tyler, President
Director Emeritus, Center for Advanced Study in the
Behavioral Sciences
Edwin Huddleson, Assistant Secretary and Financial Officer
Partner, Cooley, Godward, Castro, Huddlesson & Tatum
Lloyd Morrisett, Chairman, Investment Committee
President, The John and Mary R. Markle Foundation
The following members of the SDF staff will also be here:
Carl York
Roberta Ishihara
John Kerns
-------
∂09-Aug-85 1340 DAVIES@SUMEX-AIM.ARPA Advanced Architecture Meeting Wednesday August 14!!
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Aug 85 13:40:33 PDT
Date: Fri, 9 Aug 1985 13:39 PDT
Message-ID: <DAVIES.12133822837.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA, BHayes-Roth@SUMEX-AIM.ARPA
Subject: Advanced Architecture Meeting Wednesday August 14!!
cc: Davies@SUMEX-AIM.ARPA
Harold will present some initial thoughts on a parallel blackboard
system. He hopes to get plenty of feedback.
Meeting time is 9:30 to 11 am.
-- Byron
∂11-Aug-85 1837 ULLMAN@SU-SCORE.ARPA ["Prof. David Maier" <maier%oregon-grad.csnet@csnet-relay.arpa>: Complexity of LP evaluation]
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 11 Aug 85 18:37:23 PDT
Received: from SU-SCORE.ARPA by diablo with TCP; Sun, 11 Aug 85 18:31:15 pdt
Date: Sun 11 Aug 85 18:29:11-PDT
From: Jeffrey D. Ullman <ULLMAN@SU-SCORE.ARPA>
Subject: ["Prof. David Maier" <maier%oregon-grad.csnet@csnet-relay.arpa>: Complexity of LP evaluation]
To: nail@SU-AIMVAX.ARPA
Message-Id: <12134399851.18.ULLMAN@SU-SCORE.ARPA>
I'm forwarding this from Dave Maier. Interesting...
---------------
Return-Path: <maier%oregon-grad.csnet@csnet-relay.arpa>
Received: from csnet-relay by SU-SCORE.ARPA with TCP; Sun 11 Aug 85 07:03:19-PDT
Received: from oregon-grad by csnet-relay.csnet id aa08598; 11 Aug 85 10:02 EDT
Received: by ogcvax.ogc.uucp (4.12/OGC←1.1)
id AA02062; Sat, 10 Aug 85 10:01:09 pdt
Date: Sat, 10 Aug 85 10:01:09 pdt
From: "Prof. David Maier" <maier%oregon-grad.csnet@csnet-relay.arpa>
Message-Id: <8508101701.AA02062@ogcvax.ogc.uucp>
To: ullman@su-score.ARPA
Subject: Complexity of LP evaluation
While at MCC, Bancilhon filled me in about his method of measuring complexity
of rule evaluators with `firings'. I assume that you understand his
notions of failed, duplicate, redundant and useless firings. He made
an interesting point, that failed and useless firings are necessary to
demonstrate that the answer set is complete, that you haven't missed any
answers.
We kicked around the following idea: For a given rule set and goal,
consider all proof trees for that goal under all possible databases.
For a single database, you must invalidate all those proof trees that
don't work for that database. You invalidate a tree by finding a useless
or failed firing that covers (subsumes) one of the nodes in the tree. Thus,
the notion of optimal should be extended so that the set of firings
invalidates all illegal proof trees, but no smaller set invalidates all
trees (and finds all answers).
Francois speculated that all the methods he knew used the same firings
to invalidate the same trees, but I was able to find a counterexample.
Dave
PS. Harry's paper assumes familiarity with the Pereira and Warren paper
he references.
-------
∂11-Aug-85 2059 DAVIES@SUMEX-AIM.ARPA New mailing list: CARE-Users
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 11 Aug 85 20:58:51 PDT
Date: Sun, 11 Aug 1985 20:58 PDT
Message-ID: <DAVIES.12134427011.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: New mailing list: CARE-Users
cc: Davies@SUMEX-AIM.ARPA
I've created a new mailing list for people who use CARE (the
architecture simulator): CARE-Users@SUMEX.
The mailing list is in <architects>care-users.dis
The archive is in <architects>care-users.mail
Please send notifications of enhancements, desired capabilities, bugs,
and fixes to the list.
-- Byron
∂11-Aug-85 2138 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #10
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 11 Aug 85 21:38:19 PDT
Date: 11 Aug 85 2124-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #10
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Monday, 12 Aug 1985 Volume 1 : Issue 10
Today's Topics:
First PARSYM Survey: More Responses?
Flat Concurrent Prolog: Beta-Test Announcment
Bench Marking
HIGH TECHNOLOGY Article
----------------------------------------------------------------------
Date: Fri, 9 Aug 85 15:16:33 pdt
From: Byron Davies <PARSYM-Request@SUMEX-AIM.ARPA>
Subject: First PARSYM Survey
You still have a chance to respond to the First PARSYM Survey (to
PARSYM-Survey@SUMEX-AIM.ARPA). See V1 #9 for details. I will be
putting together a special digest of responses: if it's OK for me to
forward your response to PARSYM, let me know.
-- Byron
------------------------------
Date: Tue 6 Aug 85 23:26:40-MDT
From: Uday Reddy <U-REDDY@UTAH-20.ARPA>
Date: Fri, 26 Jul 85 15:25:56 -0200
From: Ehud Shapiro <Udi%wisdom.bitnet@WISCVM>
Subject: Beta test-sites for our Flat Concurrent Prolog
[Forwarded from Prolog Digest]
We will be ready in a month or so to release our Flat Concurrent
Prolog system to beta test sites (FCP is the And-parallel subset of
Concurrent Prolog). The system consists of an emulator for a
Warren-style FCP abstract machine, written in C, which also includes
kernels and a garbage collector; an FCP compiler, written entirely in
FCP (including the tokenizer, parser, precompiler, encoder, and
assembler); and a basic interactive programming environmnt that
includes a shell, I/O routines, and a source-level debugger, which are
also written in FCP.
The system has an interesting module system, which implements remote
procedure calls via message-passing between module manager processes.
It supports separate compilation and runtime linking.
The system runs on VAX and on the Sun under Berkeley Unix 4.2. It
runs at about the third of the speed of Quintus Prolog on the Vax for
similar programs, on a wide range of examples.
Some statistics: compiling the main module of the compiler, the
encoder, which is 8937 bytes and 418 lines of code long, takes 258 CPU
seconds on the VAX/750. The resulting binary file is 17560 bytes of
code long (at present we use word-encoding, rather then byte encoding
for the abstract machine instructions). The compilation consumes
about 1.5 Mbytes of heap memory (without garbage collection).
During this computation, 29000 processes are generated (yes, twenty
nine thousand), and altogether they perform 92000 reductions. During
the computation 13000 process suspensions occur. This gives an
effective rate of 350 process reductions per second, and an avarage of
3 reductions per process.
The system's C code is currently 5270 lines of code long, 2942 for the
emulator, 1624 for kernels, and 704 for the garbage collector. Its
FCP code is currently 4529 lines of code long, 2060 for the compiler,
324 for the debugger, 722 for I/O, and 1423 for the rest of the
system. Of course the interactive shell and the compiler share the
tokenizer and parser.
The main designers and implementors of the system are Avshalom Houri
and myself. Other contributors include Bill Silverman, Michael
Hirsch, Jim Crammond, Colin Mierowski, Steve Taylor, Muli Safra, Nir
Friedman, and Shimon Cohen. The development of the system was
supported by IBM Poughkeepsie, Data Systems Division.
The system is still under development. The major avenues of
improvement being investigated at present are extending the module
system to be hierarchical, and to integrate better the debugging and
module concepts; integrating the system with a partial evaluator;
improving the performance by optimizing the emulator and improving the
instruction set (we do not plan at present rewriting the emulator in
assembler or in micro-code); adding a window system; an independent
file-system; and other gadgets.
Longer term research includes full compilation and implementation
on a multiprocessor.
We plan to distribute the system following standard university based
software distribution practices. Before releasing the system for the
general public, we would like to obtain some feedback, and improve the
system some more. We would like to deliver it to some selected groups
with strong logic programming or concurrent programming background,
who are interested in one or more of the following:
1. Improve and extend the system in various ways.
2. Use it as a research tool for developing pilot FCP
applications.
3. Use it to teach a course in concurrent logic programming.
(we believe it is reliable enough even at present for this.
It has just begun to be used for doing course projects in
my Concurrent Prolog Programming course at the Hebrew
University and at the Weizmann Institute, so we will know
better in a few weeks).
Interested parties should contact me, with relevant information,
at:
udi%wisdom.bitnet@WISCVM.arpa
or
...!decvax!humus!wisdom!udi
We hope to sort out the details of the distribution mechanism
by mid-August.
-- Ehud Shapiro
------------------------------
Date: Fri, 9 Aug 85 15:16:33 pdt
From: Russell Brand <brand@lll-crg>
Subject: Bench Marking
What type of problems should be given to bench mark a massively parrallel
Symbolic Computing System? Clearly something from pattern matching,
tree manipulation, sort, searching, game trees...
But what would be good bench mark programs?
Suggestions for inclusion in such a suite are requested by
Russell Brand [brand@lll-crg.ARPA]
------------------------------
Date: Sat 10 Aug 85 20:10:49-EDT
From: Randy Haskins <rh%MIT-EECS@MIT-MC.ARPA>
Subject: Article about our favorite topic
The July issue of HIGH TECHNOLOGY has a pretty reasonable article on the
current progress of parallel processing technology, including an overview
on a few systems working now and some that will be up soon.
Random
------------------------------
End of PARSYM Digest
********************
∂12-Aug-85 1244 YAMARONE@SU-CSLI.ARPA Extra Turkey Sandwich
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 12 Aug 85 12:44:07 PDT
Date: Mon 12 Aug 85 12:41:39-PDT
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: Extra Turkey Sandwich
To: folks@SU-CSLI.ARPA
There is a turkey sandwich available.
First come, First full.
2.50 .
The Ventura Sandwich Corp.
-------
∂12-Aug-85 1303 @SU-CSLI.ARPA:GEORGEFF@SRI-AI.ARPA Monday Planlunch
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 12 Aug 85 13:03:41 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 12 Aug 85 12:58:44-PDT
Date: Sun 11 Aug 85 17:01:38-PDT
From: Michael Georgeff <georgeff@SRI-AI.ARPA>
Subject: Monday Planlunch
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, rsimmons@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
vanLehn@XEROX.ARPA, araya@XEROX.ARPA, frayman@XEROX.ARPA,
suchman@XEROX.ARPA, weld@XEROX.ARPA, mittal@XEROX.ARPA, dekleer@XEROX.ARPA
Experiments with Belief Resolution
Kurt Konolige and Christophe Geissler
SRI AI Center
11:00 AM, Monday, August 12
SRI International, Building E, Room EJ232
In recent work, Konolige developed a resolution rule for a quantified
modal logic of belief. However, the rule is difficult to apply in
practice, because it takes an arbitrary number of input clauses, and
some instances of the rule may subsume others. In this talk we
describe a solution to this problem based on a generalization of
semantic attachment, that controls the growth of the search space. We
have implemented the resulting version of belief resolution with
Stickel's first-order connection-graph theorem prover. We present
several examples of automatic reasoning about belief using this
system, including a solution to the wise man problem.
-------
∂13-Aug-85 1027 ullman@diablo tomorrow's meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 10:27:11 PDT
Date: Tue, 13 Aug 85 10:16:31 pdt
From: Jeff Ullman <ullman@diablo>
Subject: tomorrow's meeting
To: nail@diablo
Remember that we have a speaker-- abstract attached.
The meeting is at 1PM in MJH 352.
*****************************************
AND/OR PARALLELISM IN LOGIC PROGRAMS
by
Simon Kasif
Department of Computer Science
University of Maryland, College Park
ABSTRACT
The separation of logic and control in logic programs
has been shown to allow the programmer to write declara-
tively lucid programs whose execution is determined by the
interpreter. This appealing characteristic of logic program-
ming spurred research directed towards diversifying the
means for controlling the execution of logic programs. In
particular, parallelism in logic programs may be exploited
even when it is impossible to state a priori that two goals
may be executed concurrently, but such an opportunity may be
detected during the course of the execution.
This talk will address the problem of AND/OR parallel-
ism in logic programming. We describe a computational model
for AND/OR parallel execution of logic programs. The model
provides the primitives to describe and analyze parallel
interpreters, emphasizing the data-flow among conjunctive
goals. The effectiveness of our computational model is esta-
blished through its ability to support both old and new com-
munication paradigms for the parallel interpretation of
logic programs.
Several methods to implement AND/OR parallelism in
logic programs are investigated based on notation developed
in the model. The methods are shown to define a spectrum of
communication schemes, ranging from the set intersection
method where communication is eliminated altogether,
through methods based on producers-consumers, where communi-
cation is uni-directional and finally ending at a flexible
bi-directional scheme introduced in the paper, called the
Intelligent Channel.
The primitives that comprise the model are used to syn-
thesize two new parallel interpreters: Disjunctive System
(DS) interpreters and Intelligent Channel Interpreters. The
Intelligent Channel is a scheme we propose to constrain the
combinatorial explosion of active processes, and to elim-
inate the need to maintain a separate binding environment
for every active OR-branch.
∂13-Aug-85 1040 ullman@diablo another talk
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 10:40:51 PDT
Date: Tue, 13 Aug 85 10:33:21 pdt
From: Jeff Ullman <ullman@diablo>
Subject: another talk
To: nail@diablo
This takes place 9AM on Aug. 26 (a Monday, yet).
Nail folks may be interested.
***********************
The Magic of Partial Evaluation,
or
Meta Interpreters for Real
Ehud Shapiro
The Weizmann Institute of Science
Abstract
Enhanced meta-interpreters can implement sophisticated functions within
complex software system. Examples are explanation facilities in expert
systems, algorithmic debuggers in programming environments, and layers of
protection and control in operating systems.
However, the execution overhead of the added layer of interpretation
is unacceptable in many applications.
Partial evaluation can eliminate the overhead of meta-interpreters.
A partial-evaluator can specialize an enhanced meta-interpreter
with respect to a given program,
generating a variant of this program which inherits the enhanced
functionality of the meta-interpreter, but not its overhead.
An application of a Concurrent Prolog partial evaluator
to operating system development will be shown.
∂13-Aug-85 1225 YAMARONE@SU-CSLI.ARPA Two Turkey Sands.Available
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 12:19:30 PDT
Date: Tue 13 Aug 85 12:16:21-PDT
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: Two Turkey Sands.Available
To: folks@SU-CSLI.ARPA
There are Two Turkey sandwiches available .
2.50/each
First come , First served.
The Ventura Sandwich Corp.
-------
∂13-Aug-85 1548 ullman@diablo Porter paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 15:48:04 PDT
Date: Tue, 13 Aug 85 15:38:40 pdt
From: Jeff Ullman <ullman@diablo>
Subject: Porter paper
To: nail@diablo
Anybody who picked up a copy of Porter's paper on
Earley deduction and would also like the *even* numbered
pages, stop by my office.
∂13-Aug-85 1611 vardi@diablo Re: Porter paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 16:11:39 PDT
Date: Tue, 13 Aug 85 15:54:59 pdt
From: Moshe Vardi <vardi@diablo>
Subject: Re: Porter paper
To: nail@diablo, ullman@diablo
The amazing thing is that I have read the paper and it was completely coherent.
Moshe
∂13-Aug-85 1937 YM@SU-AI.ARPA Seminar on Control in Prolog
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 19:36:55 PDT
Received: from SU-AI.ARPA by diablo with TCP; Tue, 13 Aug 85 19:30:39 pdt
Date: 13 Aug 85 1929 PDT
From: Yoni Malachi <YM@SU-AI.ARPA>
Subject: Seminar on Control in Prolog
To: nail@SU-AIMVAX.ARPA
∂13-Aug-85 1546 GEORGEFF@SRI-AI.ARPA Seminar on Control in Prolog
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 15:43:45 PDT
Date: Tue 13 Aug 85 15:40:21-PDT
From: Michael Georgeff <georgeff@SRI-AI.ARPA>
Subject: Seminar on Control in Prolog
To: aic-associates@SRI-AI.ARPA
Lee Naish, from The University of Melbourne, will be giving a short
talk (which will also be presented at IJCAI) in EK242, immediately
after Chris Stuart's IJCAI talk at 11am, Wednesday 14th. Here is the
title and abstract:
PROLOG CONTROL RULES
We present a broad overview of the many proposals for control in
PROLOG. Two features of computation rules are used to evaluate them.
The first is the well known idea of detecting failure as soon as
possible (where is is unavoidable). The second idea is to avoid
failures, where possible. The extend to which various language
constructs and heuristics embody these two ideas is discussed. By
examining current systems in this light, several conclusions are
reached. We propose an idealized system, with a hierarchy of goals
and a fair computation rule.
-------
∂13-Aug-85 2205 @MIT-MC.ARPA:HEWITT@MIT-MC.ARPA Prolog will fail as the foundation for AI; so will LOGIC as a PROGRAMMING Language
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 22:05:14 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 14 AUG 85 01:04:41 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 14 Aug 85 01:02-EDT
Date: Wed, 14 Aug 85 01:03:48 EDT
From: Carl E. Hewitt <HEWITT@MIT-MC.ARPA>
Subject: Prolog will fail as the foundation for AI; so will LOGIC as a PROGRAMMING Language
To: phil-sci@MIT-OZ
Message-ID: <[MIT-MC.ARPA].611660.850814.HEWITT>
Folks,
This list has been rather dormant. To liven things up, I would like to throw
out the following little ticker:
Prolog (like APL before it) will fail as the foundation for Artificial
Intelligence because of competition with Lisp. There are commercially
viable Prolog implementations written in Lisp but not conversely.
LOGIC as a PROGRAMMING Language will fail as the foundation for AI because:
1. Logical inference cannot be used to infer the decisions that need to be
taken in open systems because the decisions are not determined by
system inputs.
2. Logic does not cope well with the contradictory knowledge bases inherent
in open systems. It leaves out counterarguments and debate.
3. Taking action does not fit within the logic paradigm.
∂13-Aug-85 2332 DAVIES@SUMEX-AIM.ARPA QLISP on CARE
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 23:32:36 PDT
Date: Tue, 13 Aug 1985 23:32 PDT
Message-ID: <DAVIES.12134979312.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: QLISP on CARE
cc: Davies@SUMEX-AIM.ARPA
During the last two weeks, I brought up a QLISP on CARE. It's a very
basic Lisp -- the only "primitive" functions supported so far are CAR,
CDR, CONS, some arithmetic functions, a form of DEFUN, and LOAD, to
get function definitions from files. There are no flavors, no
defstructs, no packages, no keyword arguments, no trigonometric
routines, but there is a Lisp on CARE, and it supports QLET and will
soon support the QLAMBDA form as well.
QLISP on CARE runs with all the CARE instrumentation so you can watch
QLISP processes being spawned as the QLISP computation distributes
itself through the CARE network. The QLISP-on-CARE top level is
implemented as separate servers at separate sites: there is a READ
server which takes input from the terminal; an EVAL server -- at a
separate CARE site -- that accepts expressions from the READ server
and evaluates them using QLISP; and a PRINT server which accepts
output expressions from the EVAL server and prints them to the screen.
In the first sentence, I said I implemented "a" QLISP because the
QLISP I implemented is actually a dialect of Scheme, hence might be
called QScheme. For the general advantages of Scheme, see the article
by Hal Abelson and Kent Dybvig appended below. There are a lot of
excellent technical reasons for using Scheme: it is the most
principled Lisp around and contains some interesting features that
make it better than Zetalisp or Common Lisp, as a language. But for
me, the main reason for implementing Scheme was its simplicity and
clarity. A meta-circular interpreter for Scheme (a Scheme interpreter
written in Scheme itself) is only a few pages of code. My
semicircular interpreter, written in Zetalisp, is also just a few
pages of code.
The implementation of QLET for Scheme-on-CARE took about 40 lines of
code, plus a few changes to CARE itself. The resulting code spawns
CARE processes to evaluate the QLET subexpressions and gets the
results back to the spawning process by means of CARE streams.
Because of the distributed nature of the CARE architecture, it was
easiest initially to implement a distributed version of QScheme.
There is no central shared memory: the initial top-level process
spawns computations at neighboring sites, transmitting the necessary
data and lexical environment along with the function invocation.
When Penny remarked this morning that I had diverged from my initial
plan to implement a shared-memory QLISP on CARE, I decided to see what
it would take to do that. It turns out that the elegance and
simplicity of Scheme make it very easy to see the leverage points for
converting QScheme to simulate different architectures within the CARE
scheme. The only change required to make QScheme-on-CARE a shared
memory Lisp was to have the single function APPLY-PRIMITIVE-PROCEDURE
do all memory allocation at one selected CARE node rather than
distributed through the network. Similar small changes can transform
QScheme to use a larger subset of CARE nodes as memory servers.
So much for the advantages of Scheme from the viewpoint of
implementation. Will Scheme be an adequate language for implementing
our application? This I can't answer by myself. If QLISP needs to
include Common Lisp as a subset, then we may have to wait for Lucid to
do it: Common Lisp is just too complicated for one person -- or at
least this person -- to implement. I tend to think that Scheme has a
very good set of abstraction mechanisms to support arbitrarily
complex applications, but there is no denying that it will require
some relearning and some reimplementation.
While I'm glad to have a multiprocessing Lisp running on CARE, I'd be
much happier if I could be sure that it would be useful to the
implementors of applications. I would appreciate any comments on this
issue.
-- Byron
What's Good About Scheme
The following description of Scheme is taken from the "Chez Scheme
Manual" by Kent Dybvig, with some editing by Hal Abelson:
Scheme is an applicative-order, lexically-scoped, and block-structured
dialect of Lisp. Like almost all Lisp dialects, Scheme is an
interactive language with automatic storage management for data
objects, including lists, strings, various numeric datatypes, and
symbols. Because of this, Scheme is ideally suited to symbolic and
dynamic computation. Because Scheme is interactive, it is easy to
learn Scheme by experimenting with it.
Scheme also employs lexical scoping and block structure. In this way,
it is similar to Algol 60 and Pascal and unlike traditional
(dynamically-scoped) Lisp dialects. But Scheme goes beyond either
traditional Lisp or Algol-like languages by providing procedures as
"first-class" data objects. A Scheme procedure may be passed as an
argument, returned as a value, made part of a compostive data
structure, and stored indefinitely while still retaining the
environment of its definition.
Like Scheme, Common Lisp also provides lexical scoping and first-class
procedures. However, Common Lisp does not treat procedures and data
in a uniform manner: Procedure identifiers are separate from data
identifiers, evaluation of the operator position of a combination
follows different rules than evaluation of the operand positions, and
procedures must be "quoted" in a special way if they are to be treated
as data. Scheme really does treat procedures and data uniformly,
greatly simplifying evaluation rules and cutting down namespaces, and
gaining expressive power with no loss of efficiency.
Another difference between Scheme and Common Lisp is that Scheme is
specified to be tail-recursive -- procedure calls can be evaluated
without building up space for "control stack." This permits the
definition of a wide variety of "imperative" constructs (such as loops
and other iterators) purely in terms of procedure application.
Additionally, Scheme does not prescribe the order of argument
evaluation (as does Common Lisp) so there is more freedom for the
Scheme implementor to rearrange programs for optimization or for
parallel evaluation.
As a consequence of lexical scoping and tail recursion, Scheme
encourages functional (side-effect free) programming. The
higher-order procedures that a Scheme programmer can easily construct
and use provide alternative and more elegant ways to perform most of
the computations that are usually accomplished with side-effects.
Another feature of Scheme places it beyond other Lisp dialects, and
most other programming languages as well. This is the provision for
continuations, a general control facility based on solid semantic
principles. Continuations allow the implementation of control
structures such as coroutines, non-blind backtracking, and multiple
tasks.
These semantic attributes of Scheme help the programmer to create
clear, concise, and maintainable programs and program systems.
However, the most important attribute of Scheme supporting this goal
is its simplicity. The Scheme community has staunchly resisted the
addition of new language features that have not proven themselves to
be general enough to warrant making the language larger. As a result,
Scheme is a fairly small language that relies on a small set of
underlying concepts, which once mastered, provide more power than the
less general mechanisms found in other programming languages.
A complete description of Scheme can be found in the "Revised Revised
Report on Scheme," edited by Will Clinger. This is published as a
joint technical report of the Indiana University Computer Science
Department and the MIT Artificial Intelligence Laboratory (June 1985).
∂14-Aug-85 0115 @MIT-MC.ARPA:Wayne@MIT-OZ Prolog will fail as the foundation for AI; so will LOGIC as a PROGRAMMING Language
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 01:15:47 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 14 AUG 85 04:15:31 EDT
Date: 14 Aug 1985 04:12 EDT (Wed)
Message-ID: <MDCG.WAYNE.12134997608.BABYL@MIT-OZ>
Sender: MDCG.WAYNE%MIT-OZ@MIT-MC.ARPA
From: Wayne McGuire <Wayne%MIT-OZ@MIT-MC.ARPA>
To: "Carl E. Hewitt" <HEWITT@MIT-MC.ARPA>
Cc: phil-sci%MIT-OZ@MIT-MC.ARPA, wayne%MIT-OZ@MIT-MC.ARPA
Subject: Prolog will fail as the foundation for AI; so will LOGIC as a PROGRAMMING Language
In-reply-to: Msg of 14 Aug 1985 01:03-EDT from Carl E. Hewitt <HEWITT at MIT-MC.ARPA>
The pro-Prolog/logic programming people have been out in force lately.
Following are a few comments that have struck my eye:
From an interview with Donald Michie, Research Director of the Turing
Institute, in /Expert Systems/, 2(1), Jan. '85, pp. 20-23:
\begin
ES: Are the ideas of induction and logic programming being taken up in
the United States?
DM: There are three points on which the conventional position in
America is tremendously vulnerable, to such a degree that they are
rapidly becoming a backward area in the core topics of this field. In
the surface topics to do with how to dress the screen and have icons
and so on they are so good and so professional that for a long time
they may hold their own. But in certain core themes they are missing
out. First, they haven't fully taken Prolog-style logic programming
on board. Secondly, they certainly haven't taken inductive
programming on board. Thirdly they have no conception of the critical
importance of the design of the rule language in which their skill is
expressed.
Each one of these is going to prove to be a fundamental pillar on
which the science of knowledge engineering will be built and it will
be obvious to every schoolboy in the year 2000.
\end
From ''Prolog Goes to Work,'' by Clara Y. Cuadrado and John L.
Cuadrado, /Byte/, August '85, pp. 151-158:
\begin
The verbosity of an imperative language like FORTRAN (the more modern
ones like Pascal and Ada tend to be even worse) comes as a result of
the need to specify each control path through the program in explicit
detail. Then, after large programs have been written, it is very
difficult to figure out what they do, partly because the
problem-solving logic cannot be made transparent in this manner.
Studies have shown that the amount of code a programmer produces tends
to be essentially constant regardless of the specific programming
language used. It is obvious that the fewer lines of clearer code we
use to accomplish a task, the better. And a logic-programming
language seems to be the perfect candidate for getting more work out
of fewer lines of code....
[The Cuadrados then describe, from personal experience, the vast
superiority of Prolog over Ada in writing a simulator of a data-flow
model for a high-performance signal-processing system.]
One problem with Prolog has been the fact that, when developing an
application, we are forced to write the whole thing as one giant, flat
program. Some of the new implementations are now providing a module
facility that greatly enhances the software-engineering appeal of the
language.
From the point of view of many applications programmers, what is
really needed is a facility like the ''demo'' predicate proposed by
Bowen and Kowalski [Bowen, Ken, and Robert Kowalski. Amalgamating
language and metalanguage in logic programming. Logic Programming,
K.L. Clark and S.A. Tarnlund, eds. London: Academic Press, 1982,
pages 153-172]. Their basic idea is to be able to have any number of
''theories'' active at any one time. When attempting to prove a goal,
we specify not only the goal to be proved but also the theory under
which the goal is to be proved. This facility allows us to maintain
incomplete and even inconsistent theories about an object of interest.
It provides us with a very attractive mechanism for the implementation
of nonmonotonic features.
\end
From ''Logic Programming,'' by Robert Kowalski, /Byte/, August '85,
pp. 161-177:
\begin
Many psychologists believe that human beings are not logical. Certain
schools of artificial intelligence also argue that knowledge is
inadequate for representing knowledge and belief. They argue that
logic is rigid and inflexible and that it requires human beings to be
consistent and their knowledge to be complete.
In my opinion, the critics are mistaken. The practical application of
logic requires a framework within which new knowledge can be
assimilated and beliefs can change. Such a framework for /knowledge
assimilation/ is completely compatible with logic and has many
potential applications both inside and outside computing.
[Kowalski then goes on to describe just how Prolog can handle
contradictory information, knowledge assimilation and belief
revision.]
\end
It seems possible that Prolog, and its extended logic programming
descendants, might well come into vogue and replace Lisp as the AI
language of choice. The Japanese and Europeans may be more prescient
in this case than we like to admit. Although Lisp is theoretically
more flexible and powerful than Prolog (Lisp is often described as the
''assembly language'' of AI), if, practically speaking, most of the
sorts of things we want to do in AI (natural language understanding,
expert systems, etc.) can be written more quickly and compactly, and
be debugged, maintained, and revised more easily in Prolog, then
Prolog will triumph. Perhaps Symbolics should begin to think about
marketing Prolog Machines.
∂14-Aug-85 0243 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #11
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 02:43:40 PDT
Date: 14 Aug 85 0002-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #11
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 14 Aug 1985 Volume 1 : Issue 11
Today's Topic:
Results of the First PARSYM Survey: Goals for Parallel Computing
----------------------------------------------------------------------
Date: 14 August 1984, 1:37 am
From: Byron Davies <PARSYM-Request@SUMEX-AIM.ARPA>
Results of the First PARSYM Survey
First, I thank the respondents to the First PARSYM survey. At the
very least, they have provided insight into the variety of goals held
by people working on parallel computing. There are no conclusive
results: one can't say that 63% of researchers in parallel computing
view performance as their main goal or that the average desired
performance is 1.56 orders of magnitude. What we can learn from the
survey is that some researchers are interested in specific
applications (rather fewer than might have been expected since my
original question was highly biased towards applications) while others
are interested in understanding parallelism as a physical or
metaphysical phenomenon. Some are interested in developing tools for
parallel programming; others are interested in incorporating
parallelism into existing problem-solving tools.
Here are the original questions:
1. What, if any, is your target application for parallel computing?
(Theoreticians aren't required to reply to this question.)
2. Is performance improvement your main goal in exploring parallel
computing?
3. (a) If so, what degree of performance improvement does your target
application require (in, say, orders of magnitude)? What
degree of performance improvement does your current approach
promise?
(b) If not, what else do you expect to achieve through the use of
parallelism?
Immediately below are my capsule summaries of the 15 projects
described by the 14 respondents. Each project is reviewed on two or
three lines. The first line describes the target application or
motivation for studying parallelism. The second line describes the
performance requirements/desires of the project. The third line, if
present, describes other goals and motivations for studying
parallelism.
Following the capsule summaries are the actual responses submitted.
When I initiated the survey I planned to distribute only a summary
rather than the actual responses. Since the volume of response was
more manageable than I might have hoped, and since all the respondents
gave permission for their responses to be distributed to PARSYM, I
have included the text below. Additional survey responses are
welcomed: please send them to PARSYM-Survey@SUMEX-AIM.ARPA. If you
have any comments on the conduct or the results of the survey, send
them on in.
-- Byron
<Application or motivation>
<Performance a goal? How much?>
<Other goals>
Object-oriented simulation
Performance not main goal
Selecting parallel architectures for specific simulation problems
AI reasoning
Performance main goal: desire 10 orders of magnitude (!)
Understanding parallelism in natural intelligence
Image understanding
Performance main goal: need 1-3 orders of magnitude
Implementing mammalian-type low-level vision systems
Mechanisms for describing parallel systems
Performance not a goal
Mechanisms for describing systems in general
Diagnostic expert systems
Performance main goal: expect 5 or more
Modeling spreading activation in associative memory
Performance not main goal
Ease of parallel programming
Performance main goal: desired speedup unspecified
Parallel logic programming
Performance one goal: 1-2 orders of magnitude hoped for
New models of computation
Multiprocessing Lisp
Performance main goal: desire improvements in mean AND variance,
wish for O(n), hope for O(n↑.667)
Understand new programming paradigms
Tools for parallel programming
Performance not main goal
Parallel programming language design; description of parallel systems
Blackboard-based problem solving
Performance main goal: 100x needed
Better handling of asynchronous events
Production systems in neural networks
Performance not main goal
Representation of symbolic information in the brain
General-purpose symbolic computing
Performance main goal: 10x for small applications, ??? for large
Use of large databases
Performance main goal: O(n) desired; > O(log n) hoped for
Interaction of asynchronous actors
General purpose AI applications
Performance main goal: "orders of magnitude" desired
------------------------------
Date: 07 Aug 85 07:50:48 EDT (Wed)
From: sokol@mitre.ARPA
We have one project which is looking at Object-Oriented programs relative to
parallel architectures. Specifically we have a large military simulation whic
which contain military objects which have real behaviours and procedures and
which communicate by passing messages. This forthcoming year we plan to
place our simulation on JPL's Hypercube, and possibly on several other
parallel architectures.
No, performance is not our main goal.
Our primary interest in parallelism is that it can speed up large slow AI
simulations; however our research questions are more specifically how best
to place this type of simulation on a parallel architecture, and which types
of parallel architectures are suitable for which type of simulations.
Lisa Sokol (Sokol@MITRE)
------------------------------
Date: Wed, 7 Aug 1985 09:44 PDT
From: ZVONA@SRI-AI
I'm one of the MIT connection machine designers.
1. Target application:
AI reasoning. Most immediately, semantic net access, truth
maintenance, congruence closure, semantic modulation (a
theorem-proving technique), production rule interpretation, graph
isomorphism, pattern recognition, statistical learning, ...
2. Is performance your main goal? (Yes/No)
Yes. I don't see how it could be otherwise, given that you can always
simulate parallel with serial.
3. (a) If so, (i) required performance improvement:
Hard to say. Ten orders of magnitude?
(ii) expected performance improvement:
Depends on for which algorithm. Also depends on how fast the TMC
connection machine runs, which I haven't heard yet. I suspect that it
won't do much better than break-even (with say a 3600) for most of
these things. The next generation of machine (eg the MIT/GE
connection machine) will be faster; how much so, I don't know.
(b) Other goals for parallelism:
I believe that natural intelligence has the same computational
constraints artificial intelligence does, so understanding how to use
parallelism for AI may lead to useful psychological theories.
------------------------------
Date: Wed, 7 Aug 85 10:24:25 pdt
From: glick@aids-unix (Jay Glicksman)
1. Target application:
Image understanding. Both low level and high level
(model-based) ends of the spectrum. Immediate applications are for IU
workstations and on-board real-time systems for an autonomous land
vehicle.
2. Is performance your main goal? (Yes/No)
I think this is a moot point since anything that can be done on
a parallel machine can be done on a serial one (via simulation in the
worst case). In other words I think everyone should answer yes (even in
the cases where performance improvements will make certain techniques
feasible for the first time).
3. (a) If so, (i) required performance improvement:
For the workstation application about 1 (order of magnitude)
For the ALV about 2-3 (at a minimum)
(ii) expected performance improvement:
As in (i) for the immediate future. As the machines (and
algorithms) improve add 1 order of magnitude to each.
(b) Other goals for parallelism:
Implementation of mammalian-type low-level vision algorithms.
Also (although not my particular area) mammalian-type memory and
learning structures. This will require smaller-grain processor units
(i.e. more like the Connection Machine than a Butterfly).
Jay Glicksman (glick@aids-unix)
------------------------------
Date: Wed, 7 Aug 85 10:37:53 pdt
From: coraki!pratt@Navajo (Vaughan Pratt)
1. Target application:
To develop concepts and languages for describing systems, and
to develop methods for manipulating those descriptions.
"System" is very broadly construed to cover Fortran programs,
silicon, PC boards, buses, keyboards, video displays,
information networks, telephone exchanges, logical inference
systems, systems of pulleys, molecular systems, planetary
systems, ecosystems, etc. Relevant buzzwords are "broad
applications spectrum," "concurrency," "mixed analog and
digital," and "real-time."
2. Is performance your main goal? (Yes/No)
No. It is not even a secondary goal.
3. (a) If so, (i) required performance improvement:
(ii) expected performance improvement:
Not applicable.
(b) Other goals for parallelism:
I will be satisfied if I can give good descriptions of existing
systems. Practically the only serial systems in existence are
those implied by conventional programming languages. To
describe almost any other system one must be able to cope with
parallelism, along with a number of other concepts not normally
encountered in programming languages. Even that first cousin
of the programming language, the logical inference system, is
not naturally serial - the natural structure of a proof is a
dag, not a line. My goal is to refine existing concepts and
develop new concepts that deal with variety of behavior,
temporal progression of events, concurrency of events, mixed
digital and analog levels in both data (binary data vs. analog
voltages, positions, velocities etc.) and scheduling (the
distinction between temporal precedence and real time), etc.
Some idea of the direction of the present efforts of myself and
my students can be gleaned from
Pratt, V.R., The Pomset Model of Parallel Processes: Unifying
the Temporal and the Spatial, in Proc. CMU/SERC Workshop on
Analysis of Concurrency, Springer-Verlag Lecture Notes in
Computer Science, ed. S. Brookes and A. Roscoe, Pittsburgh,
1984.
Pratt, V.R., Some Constructions for Order-Theoretic Models of
Concurrency, in Logics of Programs, Lecture Notes in Computer
Science LNCS 193, ed. R. Parikh, Springer-Verlag, Brooklyn,
June 1985.
Gischer, J., Partial Orders and the Axiomatic Theory of Shuffle,
Ph.D. thesis, STAN-CS-84-1033, Dept. of CS, Stanford University,
Dec. 1984.
Time permitting, I will try to convey some of the ideas from
these efforts to this list, to the extent that they may be
of interest to the list. It seems pretty reasonable to assume
of interest the question of what it means to be "parallel."
I am pursuing this work in parallel with research into the
graphical aspects of font design for document preparation
systems, in the course of which some unexpected and striking
parallels between algebras for process modelling and algebras
for calligraphics have emerged.
I am just now putting together a proposal for a grant to carry
out such work at Stanford and would appreciate leads on funding
agencies who might have a particular interest in this topic.
For the past decade I have relied mainly on the NSF, but
academic year support from this source has over the years been
steadily decreasing, and has now dwindled to the point where I
must begin looking elsewhere. In the interests of minimizing
bureaucracy and maximizing time available for research the work
would ideally be covered by a single grant. Under these
conditions the ideal agency would therefore presumably be one
with a particular interest in this subject, or at least some
faith in its importance.
I am sure there must be others on this mailing list who are in the
same boat with respect to both topic and funding who would also be
well served by such leads.
--Vaughan Pratt
------------------------------
Date: Wed, 7 Aug 85 14:46:52 edt
From: James A. Reggia <reggia@maryland>
Here are responses to the PARSYM survey on two projects at the
University of Maryland. For further information, contact Jim
Reggia at reggia@umcp-cs
via arpanet.
----------------------------------------------------------
FIRST PROJECT
1. Target application:
Parallel processing algorithms for diagnostic expert systems.
2. Is performance your main goal? (Yes/No)
Yes.
3. (a) If so, (i) required performance improvement:
Whatever one can obtain.
(ii) expected performance improvement:
Speedup of 5 or more.
(b) Other goals for parallelism:
Note: This project is just starting this Fall.
---------------------------------------------------------
SECOND PROJECT
1. Target application:
Spreading activation model of associative memory.
2. Is performance your main goal? (Yes/No)
No.
3. (a) If so, (i) required performance improvement:
(ii) expected performance improvement:
(b) Other goals for parallelism:
The purpose of this project is to study a new method for controlling
spreading activation in parallel activation networks. This is a project
in cognitive science. (See forthcoming paper in IJCAI Proceedings
late August).
------------------------------
Date: Wednesday, 7 August 1985 12:03-PDT
From: Tony Li <Tli at Usc-Eclb>
1. What, if any, is your target application for parallel computing?
(Theoreticians aren't required to reply to this question.)
Hmmm... I'm not a theoretician, but I don't think I have a simple
answer. Basically, I'm interested in developing programming
languages that make it *trivial* to write parallel programs.
2. Is performance improvement your main goal in exploring parallel
computing?
Yes...
3. (a) If so, what degree of performance improvement does your target
application require (in, say, orders of magnitude)? What
degree of performance improvement does your current approach
promise?
Any significant amount of speedup would be welcome.
;-)
------------------------------
From: "David M. Meyer"
From: <meyer%tekchips%tektronix.csnet@csnet-relay.arpa>
Date: Wednesday, 7 Aug 85 08:03:27 PDT
1. Target application:
I am interested in other (parallel) models of computation,
specifically, parallel interpretation of "logic" programs.
However, I am in general interested in novel models of computation.
2. Is performance your main goal?
Yes/..and No -- We need to show that we can do things
(for instance, execute benchmarks) faster, but there
are other reasons for exploring parallelism
(see 3 (b) below). Sorry.
3. (a) If so, (i) required performance improvement:
Probably at least an order of magnitude (or 2)...
(ii) expected performance improvement:
????
(b) Other goals for parallelism:
We/I would like to break out of our "von Neumann" mold,
and develop some truely "non-Von" models of computation.
This, of course, requires some novel approaches to an entire
programming system: the language used, and systems architecture.
Perhaps here a more top-down, or "language first" approach will
be useful.
Dave ---
David Meyer
Tektronix, Inc.
P.O. Box 500
MS 50-662
Beaverton, OR 97077
usenet: {decvax, allegra}!tektronix!tekchips!meyer
csnet: meyer%tekchips@tektronix.csnet
arpanet: tekchips!meyer%tektronix.csnet@csnet-relay.arpa
------------------------------
Date: Thu, 8 Aug 85 12:12 EDT
From: Seth Steinberg <sas@BBN-VAX.ARPA>
1. Target application:
A multiprocessor LISP system. We hope to support up to 256 68000
processors on a Scheme/Common LISP hybrid.
2. Is performance your main goal? (Yes/No)
Yes, in two senses. Overall time improvement. Statistical stability
in solution time. (Make the solution time less dependent on the
particular answer and more dependent on the question).
3. (a) If so, (i) required performance improvement:
O(number of processors)
(ii) expected performance improvement:
O(number of processors ↑ 2/3)
[How's that for speculation.]
(b) Other goals for parallelism:
Understanding new programming paradigms.
[Good and vague.]
Seth Steinberg
(These opinions are my own and while they are consonant with those of
my employer they are not necessarily identical).
------------------------------
Date: Thu, 8 Aug 85 18:31:27 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
1. Target application:
I'm not sure how to answer this. I'm on this mailing list because I'm
interested in developing tools for use on parallel architectures.
2. Is performance your main goal? (Yes/No)
Not -my- goal. It is certainly important to the people who might use the
tools I'm interested in designing.
3. (a) If so, (i) required performance improvement:
(ii) expected performance improvement:
(b) Other goals for parallelism:
I'm interested in parallel programming language design. I'm interested in
how a programing language can help people explain how to do a zillion
things at once without becoming confused.
------------------------------
Date: Thu 8 Aug 85 19:32:27-PDT
From: Mike Hewett <HEWETT@SUMEX-AIM.ARPA>
1. Target application: BB1 (blackboard) Problem-Solving environment
2. Is performance your main goal? (Yes/No) Yes. Both Speed and Versatility
3. (a) If so, (i) required performance improvement: 100x
(ii) expected performance improvement: unknown
(b) Other goals for parallelism:
Provide versatility for handling blackboard events which
are caused by "outside" sources.
------------------------------
Date: 10 Aug 85 11:49 EDT
From: Dave.Touretzky@CMU-CS-A.ARPA
1. My target application is to implement a production system interpreter
in a neural network architecture. This is work I am doing with Geoffrey
Hinton, also at CMU, as part of the Boltzmann Machine research effort.
2. Performance improvement is not our main goal.
3. Our objective is to explore ways in which symbolic information can
be represented and used within the brain. We are pursuing this question
by designing neural network models of increasing sophistication, in order
to elicit techniques for organizing massively parallel symbolic reasoning
that might, eventually, be shown to have some analog in actual living
systems. We consider this goal to be a long way off, but we have had some
short term successes, most notably in successfully implementing a
production system interpreter using 7-8000 simulated neurons on a Symbolics
3600. This work is described in our forthcoming IJCAI paper.
-- Dave Touretzky
------------------------------
Date: Mon, 12 Aug 85 11:00:34 edt
From: Bert Halstead <rhh%mit-vax@mit-mc>
For the Multilisp project at MIT:
1. Target application: general-purpose symbolic computing (this is kind
of a cop-out, but the intent is to provide tools to facilitate high
performance symbolic computing, rather than to implement any one
application).
2. Is performance your main goal? Yes
3. (a) (i) required performance improvement: the more the better
(ii) expected performance improvement: highly application
dependent, but 10x seems easy even for many rather
small applications. An interesting question is how
much we can achieve for larger applications.
------------------------------
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.ARPA>
Date: Wed 7 Aug 85 00:20:58-PDT
1. Target application: Knowledge-base technology for large databases.
2. Is performance your main goal? (Yes)
3. (a) If so, (i) required performance improvement: O(n), i.e., modest --
(other techniques will be explored prior)
(ii) expected performance improvement: > O(log n)
(b) Other goals for parallelism: Interaction of asynchronous actors
Gio Wiederhold KBMS - KSYS project
------------------------------
From: linus!brando@Mitre-Bedford
Date: Tue, 13 Aug 85 11:15:09 edt
1. Target application: General-purpose AI applications
2. Is performance your main goal? Yes
3. (i) Our stated goal is "orders of magnitude improvement in processing
speed for all classes of AI computations"
(ii) We cannot predict at this time the actual performance improvement of
our current approach
-------------------------------------------------------------------------------
Thom Brando linus!brando@MITRE-BEDFORD.ARPA
{allegra,decvax,ihnp4,philabs,utzoo,uw-beaver,...}!linus!brando.uucp
------------------------------
End of PARSYM Digest
********************
∂14-Aug-85 0922 @MIT-MC.ARPA:DAM@MIT-OZ Symbolics Prolog
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 09:22:45 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 14 AUG 85 12:15:07 EDT
Date: Wed, 14 Aug 1985 11:09 EDT
Message-ID: <DAM.12135073491.BABYL@MIT-OZ>
From: DAM%MIT-OZ@MIT-MC.ARPA
To: Wayne%MIT-OZ@MIT-MC.ARPA
cc: phil-sci%MIT-OZ@MIT-MC.ARPA
Subject: Symbolics Prolog
Date: Wednesday, 14 August 1985 04:12-EDT
From: Wayne McGuire <Wayne>
Perhaps Symbolics should begin to think about marketing Prolog
Machines.
Symbolics recently anounced a PROLOG system. I think it
has been billed as "the fastest PROLOG in the world". This
software product has proved to be extremely popular;
Symbolics is selling PROLOG systems like hotcakes.
∂14-Aug-85 0936 @SU-CSLI.ARPA:barwise.pa@Xerox.ARPA Robin Cooper's Title
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 09:34:16 PDT
Received: from Xerox.ARPA by SU-CSLI.ARPA with TCP; Wed 14 Aug 85 09:31:47-PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 AUG 85 09:31:04 PDT
Date: 14 Aug 85 09:30 PDT
From: barwise.pa@Xerox.ARPA
Subject: Robin Cooper's Title
To: Researchers@su-csli.ARPA
cc: barwise.pa@Xerox.ARPA
Message-ID: <850814-093104-5099@Xerox>
Robin Cooper is talking today at 2 PM. His title is "Unification in
Situation Semantics: Linguistic Arguments?" The talk will be in the
Ventura Conference Room.
∂14-Aug-85 0958 @MIT-MC.ARPA:Vijay.Saraswat@CMU-CS-C.ARPA On logic programming as a foundation for AI.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 09:57:45 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 14 AUG 85 12:48:07 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 14 Aug 85 12:19-EDT
Received: from CMU-CS-C.ARPA by MIT-MC.ARPA 14 Aug 85 12:07:55 EDT
Received: ID <SARASWAT@CMU-CS-C.ARPA>; Wed 14 Aug 85 12:07:08-EDT
Date: Wed 14 Aug 85 12:07:05-EDT
From: vijay <Vijay.Saraswat@CMU-CS-C.ARPA>
Subject: On logic programming as a foundation for AI.
To: phil-sci%MIT-OZ@MIT-MC.ARPA
cc: saraswat@CMU-CS-C.ARPA
This is a response to some of the issues recently raised by Hewitt in
a post to the PHIL-SCI digest. (Phil SCI Digest, Aug 14).
For the sake of argument, Prolog is probably a `more convenient' language for
writing compilers than Lisp; on the other hand, the current state of
sophistication of Lisp implementations makes them extremely attractive for
developing rapid prototype implementations. For the near future I see
the ideal programming environment as being a Lisp Machine with a very fast
Prolog on it (If Symbolics Prolog lives up to rumours of 100K Lips that will
do, thank you.) Why would anyone EVER want to write a CommonLisp interpreter
in Prolog? There are much better things to do ... particularly when you
already have CommonLisp and Prolog!
What does this have to do with "being a foundation for AI"? If he means that
"X is a foundation for AI" if X is used by most people for writing their AI
programs, then that is irrelevant. I would say that "X is a foundation for AI"
if most work being carried out in AI can fit in the theoretical framework of
X. With such a working definition it is rather doubtful if any one paradigm can
be a foundation for AI. But I would submit that the concept of logic
programming is a step towards reaching such a foundational understanding.
"Logic as a programming language will fail as the foundations for AI
because..."
Let's be careful how we bandy terms around. Logic is not a programming
language. Logic is logic, a formal system. The first axiom of logic programming
(the LOGIC axiom) is that the definite clause subset of logic has an appealing
interpretation as a programming language, if the process of SLD-refutation
(which is complete for this subset) is taken as the inference mechansim. In
this programming language, the user has DON'T KNOW CHOICE, i.e. the power of
specifying existential searches. This power is rather unnerving. The second
axiom of logic programming (the CONTROL axiom) is that it is possible to
provide general control mechanisms which can be exploited by a programmer for
controlling the search. This led to the rise of logic programming languages,
which allow, in general, the programming of incomplete searches, (hence the
handling of non-montonic inference, defaults, inheritance ...).
The most ancient of these is PROLOG, which essentially provided the control
structure of SEQUENTIALITY. The language PROLOG has something to do with logic
of course, but, because of its incomplete proof procedure, its semantics is
best given via denotational means, rather than logical means. This is the
first corollary of logic programming: a formal understanding of logic
programming languages has to appeal to traditional computer science techniques
for giving semantics to programming languages. The surprising discovery is
that because of the simplicity of the underlying execution mechanism such
semantics are surprisingly simple: far simpler than semantics for ALGOL,
LISP (has anyone ever attempted a semantics for something like COMMONLISP?),
ACTORS... This has very powerful connotations with respect to semantically
based programming environments, program transformations, and meta-programming.
There have been more recent languages which have provided other control
features: PARLOG, GHC, Concurrent Prolog and CP[!,|,&], to name just a few in
the main stream of Horn logic programming, have attempted to also provide don't
care choice and parallelism. To frame it in the current parlance, these
languages essentially provide support for object-oriented programming.
While a formal denotational semantics for the last is still being developed
(the others do not yet have formal semantics), it has already been demonstrated
that it has a surprisingly simple partial correctness semantics.
More important, these languages demonstrate that while keeping the LOGIC
component more or less identical, it is possible to achieve a great variety of
operational behaviours by changing the CONTROL component. Hence logic
programming is not a LANGUAGE, it is a PROGRAMMING PARADIGM encompassing all
these operational behaviours.
To sum up, logic programming langauges are not just any programming languages,
at some level, most programs written in such languages have a declarative
interpretation compatible with a logic system, typically universally quantified
definite clause logic. Logic programming languages are not just logic systems
because their control component plays an important part. The art of designing
logic programming languages is concerned with maintaining a delicate balance
between these two divergent themes. Even with their control components, logic
programming languages can generally be given simple semantics, which reflects
their underlying conceptual simplicity.
As far as supporting most of the current AI paradigms is concerned, it should
be clear that Definite clause logic supports naturally the notions of
goal-driven backward chaining.
It is my contention (as yet unsupported) that the basic style of computation
provided by Concurrent Prolog and CP[!,|,&] naturally supports data-driven,
forward-chaining inference and also knowledge-structuring a la semantic
network based languages, again via the primary mechanism of message-passing.
("reserach in progress", though there is an article by Shapiro andd Takeuchi
on object oriented programming in Concurrent Prolog).
Hence I would conclude that, to the extent that logic programming languages
support such programming paradigms, and to the extent that they themselves
have secure theoretical foundations, one can at least claim that logic
programming offers a step towards a unified understanding of the foundations of
(programming paradigms used in) AI.
Note that I am not saying anything at all about the psychological plausibility
of controlled inference as the essential "problem-solving capability" in
intelligent agents.
Let me now discuss three specific poinst raised by Hewitt:
"1. Logical inference cannot be used to infer the decisions that need to be
taken in open systems because the decisions are not determined by system
inputs.
2. Logic does not cope well withthe contradictory knowledge bases inherent
in open systems. It leaves out counterarguments and debate.
3. Taking action does not fit within the logic paradigm."
Some of these contentions have been made by Hewitt in other contexts and I
still remain as mystified by them as I was then.
Let us keep in mind that we are talking of programming langauges, albeit
peculiar programming languages. How does a LISP function 'take action'?
Presumably by doing a (setq foo 'take-action). How does an OPS-5 program take
action? Presumably by executing a (make task-312 ↑task take-action) on the
right hand side of a production. So also logic programming languages
take action by instantiating a variable to some value. If that variable was
actually implemented as a particular memory cell which is being monitored by a
hard-wired coke-dispenser, then it would 'take action': deliver a coke bottle.
Presumably what is confusing Hewitt is that in Prolog bindings can be done on
backtracking. But all that is in the programmer's control! If the programmer
intended that the action to be taken is irrevocable, he would write his axioms
in such a fashion that the binding would not be backtracked over. That is
a control problem!
About contradictory data bases. First let me make the obvious statement that a
certain level of understanding, every set of definite clause has a model,
indeed an infinity of models. Hence there is no scope for representing
contradictory knowledge directly via axioms in a Horn logic program.
So how do logic programming systems do it? Well you have to PROGRAM IN your
handling of such data. You have to write a program, just as you would write a
program in LISP or ATOLIA which does to this data what you want to do with it.
The axioms you write (the program you write) will be executed in the fashion
determined by the logic programming language you choose and by the control you
provide: usually this approximates some kind of inferencing. BUt the action
that
gets taken when you execute your program depends upon your program. If you had
written your program such that when you encounter an inconsistency it would
print out "The moon is made of green cheese" and stop, then, if an inconsitency
is encountered, believe it or not, it will print out "The moon is made of green
cheese" and stop. If you wanted to program in counterargumentsd and debate then
go ahead and do that. Logic programming does not provide "counterarguments and
debate" as a primtive concept. The advantage that you get by writing your
program in a logic programming language is that you can reason about it, you
can (hopefully) prove that when the program encounters an inconsistency it will
print out "The moon is made of greencheese" and terminate. And because of the
simplicity of the programming paradigm that you are using, your proofs would be
relatively simple. If you were careful in writing your program and in choosing
your logic programming langauge, the answer that you would get would be a
logical consequence of YOUR AXIOMS (program) which of course COULD HAVE DONE
whatever it wanted to to the data.
Hence, while on the face of it Hewitt's statement (2) is true, it is totally
irrelevant.
This also takes care of the argument that "logical inference cannot be used to
infer decisions that need to be taken in open systems ..." because logical
inference is being used to execute YOUR PROGRAM, which determines how to make
those decisions. If your program is actually an OPS-5 interpreter which acts
on the data that it gets by using a knowledge base of productions, then, by
heavens, YOUR PROGRAM is NOT doing logical inference. Hence even if Hewitt's
contention is correct, it is totally irrelevant.
Vijay A. Saraswat
CMU-CSD
(References for some of the work cited herein are available on request. Or if
there is sufficient interest, I can send them to the Phil-sci digest.
-------
∂14-Aug-85 1107 @MIT-MC.ARPA:Laws@SRI-AI.ARPA Challenge Problem
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 11:07:17 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 14 AUG 85 14:07:15 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 14 Aug 85 13:53-EDT
Received: from SRI-AI.ARPA by MIT-MC.ARPA 14 Aug 85 13:51:34 EDT
Date: Wed 14 Aug 85 10:49:57-PDT
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Challenge Problem
To: Phil-Sci%MIT-OZ@MIT-MC.ARPA
I have long believed that any algorithm developed in a procedural
language could be reformulated more elegantly in a logic language.
This may be true, but I have come to doubt its utility. Restating
an algorithm in nonprocedural form can be a useful exercise, but does
not improve on the procedural nature of the algorithm. Advocates
of logic programming would have a weak case if their languages were
just notations for telling the computer what to do, step by step.
In order to sharpen my understanding of logic programming, I would be
interested in hearing about logic-based solutions to a problem that I
consider particularly "algorithmic": extraction of connected
components in images. I would like to learn of any logic-based
approach to the problem that would entail neither massive search nor
such extensive procedural embedding as to make the "logic" portion
trivial.
The problem: Assume that you have an array of integers, and are to
identify all maximal connected components -- i.e., all clusters of
identical integers. The integers range from 0 to some known maximum,
with 0 being a special code that connects with the space "outside" the
array. You are free to use any bounded intermediate data structures.
The output is to consist of an array in which elements of each connected
component are marked with the same integer code, and elements of different
components are marked with different codes. Other outputs (boundary
traces, lists of region adjacencies and inclusion relationships, number
of holes per region, etc.) are desirable but of secondary importance.
I know of several good algorithms for solving this problem. Most involve
an intermediate map or equivalent data structure that records nonmaximal
connected components found during a row-by-row scan, together with a
list of discovered equivalences that can be used to link these into
maximal components. Such algorithms are quite efficient (aside from
having to scan the array completly, in the worse case, before starting
to build the output map). Others involve visiting (and marking) every
point in the array, tracing region boundaries until they close and then
raster scanning to find the next unvisited point. (This is a reasonable
procedure if the boundary traces are of primary interest.)
Is there any hope that a logic-based language could compile a
[nonalgorithmic] declarative statement of this problem into similar
code, or would the compiler have to be guided by domain knowledge that
essentially supplies it with the right answer? If the latter is true,
in what sense is logic programming the answer to our current needs?
-- Ken Laws
-------
∂14-Aug-85 1258 NET-ORIGIN@MIT-MC.ARPA Re: Prolog will fail as the foundation for AI; so will LOGIC as a PROGRAMMING Language
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 12:58:29 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 14 AUG 85 15:57:15 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 14 Aug 85 15:52-EDT
Received: from Uiuc.ARPA by MIT-MC.ARPA 14 Aug 85 11:23:51 EDT
Received: from uiucdcsp.Uiuc.ARPA (uiucdcsp.ARPA) by Uiuc.ARPA (4.12/4.7)
id AA19858; Wed, 14 Aug 85 10:24:03 cdt
Received: by uiucdcsp.Uiuc.ARPA (4.12/4.7)
id AA07991; Wed, 14 Aug 85 10:23:10 cdt
Date: Wed, 14 Aug 85 10:23:10 cdt
From: forbus%uiucdcsp@Uiuc.ARPA (Kenneth Forbus)
Message-Id: <8508141523.AA07991@uiucdcsp.Uiuc.ARPA>
To: HEWITT@MIT-MC.ARPA, Wayne%MIT-OZ@MIT-MC.ARPA
Subject: Re: Prolog will fail as the foundation for AI; so will LOGIC as a PROGRAMMING Language
Cc: phil-sci%MIT-OZ@MIT-MC.ARPA, wayne%MIT-OZ@MIT-MC.ARPA
(Carl, I wish you had found a fresher topic to re-open the list with.
And doing it right before conference season...)
To equate "prolog" with "logic programing, as Carl & Wayne's messages comes
very close to doing, is somewhat less than accurate. True, prolog is
currently the logic programming language of choice. True, prolog provides a
handy notion of variable that takes painful effort to build in Lisp. But
prolog really is "Micro-Planner done right", as its advocates claim, and
that is enough to allow most AI people to tune out prolog because we found
out a long time ago that Micro-Planner isn't what we want.
Prolog suffers from being both too old and too new. It is too old, in the
sense that it has chronological backtracking built into its roots and the
standard versions don't take into account new ideas (such as TMS').
Yes, of course one can encode these things in logic and "run them" in
Prolog (If you really believe prolog is "programming in logic" I have
a bridge to sell you). However, you may not get an answer in the lifetime
of the universe, and doing three or four experiments will have you sitting
fruitlessly at the console long enough to write a fast lisp program to do
the same thing! But prolog is too new, in that it has also not kept pace
with progress in programming environments and language design. Talking
to prolog programmers is a bit like talking to lisp programmers 10
years ago -- there are many dialects, often changing rapidly, wild
disagreements on syntax, etc. The days of CommonProlog are likely to be
pretty far off.
Judging the idea of logic programming by prolog is a bit like judging lisp
by Lisp 1.5. I believe that only a tiny fraction of the interesting ideas
which should be encapsulated in a real logic programming language have been
developed. If some venture capitalist were to ask me into whose pocket
should he put $1M to get a signficant advance in the state of logic
programming, I wouldn't suggest spending it on the prolog community. I'd
probably suggest splitting it between McAllester & de Kleer, whose ideas on
TMS', while rather different, are both far more interesting and potentially
productive ideas than, say, improving the speed of unification or studying
and-parallelism. We simply don't have enough experience writing and using
reasoning languages yet to either cast our ideas into stone (i.e., adopt
prolog and spend our time optimizing it) OR pass final judgement on the
merits of logic programming.
On logic and action: Why shouldn't Shakey be considered a counter-example
to Carl's claim about the impossibility of action in a system based on
logic? Shakey used resolution theorem proving to decide what to do and
other kinds of routines (such as A* search) to flesh out the details. If
the existence of these other routines is considered sufficient to discount
Shakey as a counterexample then the claim seems rather uninterestingly
obvious.
∂14-Aug-85 1614 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA PLANLUNCH break -- for next three weeks
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 16:14:21 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Wed 14 Aug 85 16:08:11-PDT
Date: Wed 14 Aug 85 16:05:38-PDT
From: LANSKY@SRI-AI.ARPA
Subject: PLANLUNCH break -- for next three weeks
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, rsimmons@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
vanLehn@XEROX.ARPA, araya@XEROX.ARPA, frayman@XEROX.ARPA,
suchman@XEROX.ARPA, weld@XEROX.ARPA, mittal@XEROX.ARPA, dekleer@XEROX.ARPA
Due to IJCAI, summer vacations, and Labor Day, we will be having NO planlunches
for the next three weeks. The series will resume on September 9, so keep
posted. Also, if anyone out there would like to give a planlunch talk, please
contact either myself (LANSKY@SRI-AI) or Mike Georgeff (GEORGEFF@SRI-AI).
-Amy Lansky
-------
∂14-Aug-85 1743 EMMA@SU-CSLI.ARPA Newsletter August 15, No. 41
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Aug 85 17:43:24 PDT
Date: Wed 14 Aug 85 16:54:40-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter August 15, No. 41
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
August 15, 1985 Stanford Vol. 2, No. 41
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, August 15, 1985
12 noon TINLunch
Ventura Hall No Lunch this week
Conference Room
2:15 p.m. CSLI Talk
Ventura Hall ``Relevant Arithmetic and Automatic Theorem Proving''
Conference Room Bob Meyer, Australian National University
(Abstract on page 1)
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
ANNOUNCEMENT
No activities have been scheduled for next Thursday, August 22.
←←←←←←←←←←←←
ABSTRACT FOR THIS WEEK'S TALK
``Relevant Arithmetic and Automatic Theorem Proving''
Thursday, August 15, 2:15 pm
Relevant logics were first developed in the 1950's, as systems
satisfying improved versions of the deduction theorem, designed better
to capture the relation between premises and conclusion in an ordinary
valid argument. The time has come to implement the design philosophy
by exhibiting some valid arguments. Those familiar with relevant
deductive technique will appreciate the point that one would not wish
to do this without a computer. Relevant technique, whose major root
has always been deduction-theoretic, does lend itself quite nicely to
mechanization. The program KRIPKE developed at LaTrobe, Melbourne,
and Australian National universities with (and by, mainly)
Thistlewaite and McRobbie realizes this technique for the system LR,
applying a sophisticated decision procedure due to Kripke. KRIPKE is
Gentzen-based, but invokes semantic constraints to keep proof searches
within reasonable bounds. The pay-off is the obvious one; by limiting
the supply of premises from which a conclusion can reasonably come
(which was the idea behind relevant logics all along), the path to a
proof is fast and efficient. Our aim now is to adapt these methods to
concrete theories, as part of a 5-year project beginning in early
1986. We have chosen arithmetic as our first area of concentration,
since it has a smooth first-order relevant formalization (in the
system R#), with many distinctive features. --Bob Meyer
!
Page 2 CSLI Newsletter August 15, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
CSLI TALK
``On the Complementarity of Subject and Subject-verb Agreement''
Edit Doron, CSLI
Wednesday, August 21, 1:30 pm, Ventura Seminar Room
``Pro-drop'' languages allow a null subject in conjunction with
rich inflectional morphology on the verb. This paper is concerned
with the other side of the ``pro-drop'' coin: a null subject is
sometimes REQUIRED under those conditions. The Celtic languages
typically impose such complementarity, and Hebrew does so to some
extent. I will point out some problems with McCloskey and Hale's
``agreement'' analysis for the data, and will propose a variant of the
``incorporation'' analysis.
←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
Summary of the meeting on Thursday, August 8
A class of five morphemes in Finnish, traditionally called
possessive suffixes (henceforeward Px), raises interesting questions
about the relationship of morphological structure to syntactic
functions. Px's appear to be pronominal (or anaphoric) elements
attached to nominal words (nouns and some adjectives, including
nominalized verbs and participals) following number and case suffixes.
Recent analyses have treated Px's as clitics, that is, parts of
phonological words that are not placed within words exclusively by the
morphology. I argue in two parts, however, that Finnish possessive
suffixes are best analyzed as true suffixes.
The talk, comprising part one of my argument, dealt with
phonological, morphological, and semantic evidence for the suffixal
(or morphological word-internal) status of the Px's. I argued that
any allomorphy or morphophonological alternation in Finnish that is
sensitive to word boundaries treats the undisputed suffixes and Px's
alike as being inside the word and treats a class of clitics as being
outside the word. Furthermore, a variety of semantically
idiosyncratic lexical items containing Px's provide further support
for a suffixal analysis of Px's, insofar as suffixes are more
susceptible to idiosyncratic lexicalization than clitics. I then
argued against the possibility that Px's are lexical level clitics
(i.e., clitics that attach to words at the morphological level) by
showing that it is quite costly to the theory of lexical phonology to
have a lexical level in Finnish that contains all of the undisputed
suffixes yet excludes the Px's; hence Px's must occupy the same
lexical level as other suffixes. Considering, then, all of the
evidence favoring a suffixal analysis for the Px's, it is extremely
weak to set Px's apart from the other suffixes solely on the basis of
morpheme order. If the syntactic facts involving Px's can be analyzed
competently from an entirely lexical basis, then a clitic analysis is
unmotivated and a suffix analysis is correct. Part two of my
argument, to be presented in a later talk, involves such a syntactic
analysis of the Px's. --Jonni Kanerva
!
Page 3 CSLI Newsletter August 15, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
SDF BOARD VISIT
The Board of Trustees of the System Development Foundation visited
Ventura Hall last Monday morning (August 12).
The members of the Board who were here are:
Arnold Beckman, Chairman
Chairman, Beckman Instruments, Inc.
Ralph Tyler, President
Director Emeritus, Center for Advanced Study in the Behavioral
Sciences
Edwin Huddleson, Assistant Secretary and Financial Officer
Partner, Cooley, Godward, Castro, Huddlesson & Tatum
Lloyd Morrisett, Chairman, Investment Committee
President, The John and Mary R. Markle Foundation
Carl York and Roberta Ishihara, two members of the SDF staff, were
also here.
-------
∂15-Aug-85 0819 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa THE SEVENTH THEORY DAY at Columbia University
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 15 Aug 85 08:18:53 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 15 Aug 85 08:15:20-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Thu 15 Aug 85 08:15:16-PDT
Received: by wisc-rsch.arpa; Thu, 15 Aug 85 09:57:50 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Thu, 15 Aug 85 08:31:54 cdt
Message-Id: <8508151331.AA28042@wisc-crys.arpa>
Received: from COLUMBIA-20.ARPA by wisc-crys.arpa; Thu, 15 Aug 85 08:31:47 cdt
Date: Thu 15 Aug 85 09:30:36-EDT
From: Susan A Maser <MASER@COLUMBIA-20.ARPA>
Subject: THE SEVENTH THEORY DAY at Columbia University
To: theory@WISC-CRYS.ARPA
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
THE
SEVENTH THEORY DAY
at Columbia University
Sponsored by the Department of Computer Science
Friday, September 27, 1985
10:00 PROFESSOR JOHN E. HOPCROFT
Cornell University
"MATHEMATICAL PROBLEMS IN OBJECT
REPRESENTATION SYSTEMS"
11:00 PROFESSOR LASZLO LOVASZ
Eotvos Lorand University, Budapest, Hungary
"MATCHINGS, POLYHEDRA,
LATTICES, AND ALGORITHMS"
2:00 DR. FAN K.R. CHUNG
Bell Communications Research
"DYNAMIC SEARCH ON GRAPHS"
3:00 PROFESSOR TOM LEIGHTON
Massachusetts Institute of Technology
"WAFER-SCALE INTEGRATION AND
THE GRID RECONSTRUCTION PROBLEM"
Coffee will be available at 9:30 a.m.
All lectures will be in the Kellogg Conference Center on the
fifteenth floor of the International Affairs Building, 118th
Street and Amsterdam Avenue.
The lectures are free and open to the public.
Call (212) 280-2736 for more information.
-------
∂15-Aug-85 0831 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa my new address
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 15 Aug 85 08:31:34 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 15 Aug 85 08:15:28-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Thu 15 Aug 85 08:15:26-PDT
Received: by wisc-rsch.arpa; Thu, 15 Aug 85 09:55:47 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Wed, 14 Aug 85 22:30:16 cdt
Message-Id: <8508150330.AA25588@wisc-crys.arpa>
Received: from csnet-relay.arpa by wisc-crys.arpa; Wed, 14 Aug 85 22:30:11 cdt
Received: from ibm-sj by csnet-relay.csnet id ct02026; 14 Aug 85 23:13 EDT
Date: Tue, 13 Aug 85 15:25:42 PDT
From: Avi Wigderson <avi%ibm-sj.csnet@csnet-relay.arpa>
To: theory@wisc-crys.ARPA
Subject: my new address
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
Hi
To those of you who may send me (regular) mail or call me,
starting Monday, August 19 I will be at Berkeley:
Mathematical Sciences Research Institute
1000 Centenial Dr.
Berkeley, CA 94720
Tel: 415-643-6056
Avi Wigderson.
∂15-Aug-85 1425 ullman@diablo papers received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 15 Aug 85 14:25:01 PDT
Date: Thu, 15 Aug 85 14:15:26 pdt
From: Jeff Ullman <ullman@diablo>
Subject: papers received
To: nail@diablo
Thanks to our flurry of visitors yesterday, I have received the
following papers:
Lloyd and TOpor: "A basis for deductive database systems II"
This is related to Lloyd's recent talk--shame on database
people for not proving "correctness" of relational algebra/calculus
in a model-theoretic sense (I guess).
Kasif: "Control ad Data Driven Execution of Logic Programs"
"The Intelligent Channel"
"Are the logic and control in logic programs always disjoint?"
Naish: A complete copy of his thesis.
"All-solutions predicates in Prolog"
I also have many copies of the even numbered pages of Porter's paper.
Drop by if you want to look at any of this.
Perhaps someone might even (mirable dictu) want to present a seminar
on one.
∂16-Aug-85 0125 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #12
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 01:22:27 PDT
Date: 16 Aug 85 0111-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #12
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Friday, 16 Aug 1985 Volume 1 : Issue 12
Today's Topics:
First PARSYM Survey: Another entry
Seminar -- Parallelism in Logic Programs
Parallel processing and economics & theorem proving
Parallel algorithms for linear programming
----------------------------------------------------------------------
Date: 15 August 85 10:09-EDT
From: BYKAT%UTCVM.BITNET@Berkeley
Subject: First PARSYM Survey
I am a bit late, but hope not too late! Here is one of my projects:
1. Target application:
Parallelity in parsing NL utterances ( + generation of
representation of their meaning which supports parallel
retrieval of information from a knowledge base).
2. Performance a goal?
Yes, performance is an important goal.
3. Required performance?
Expect, and hope for, an improvement of at least one order
of magnitude
Alex Bykat
BitNet address: BYKAT@UTCVM
------------------------------
Date: Tue, 13 Aug 85 01:11:28 EDT
From: Steven A. Swernofsky <SASW@MIT-MC.ARPA>
Subject: Seminar -- Parallelism in Logic Programs
[Excerpted from the IBM-SJ Calendar by Laws@SRI-AI.]
IBM San Jose Research Lab
5600 Cottle Road
San Jose, CA 95193
Fri., Aug. 16 Computer Science Seminar
2:00 P.M. PARALLELISM IN LOGIC PROGRAMS
Aud. A The separation of logic and control in logic
programs has been shown to allow the programmer
to write declaratively lucid programs whose
execution is determined by the interpreter.
This appealing characteristic of logic
programming spurred research directed towards
diversifying the means for controlling the
execution of logic programs. In particular,
parallelism in logic programs may be exploited
even when it is impossible to state a priori
that two goals may be executed concurrently, but
such an opportunity may be detected during the
course of the execution. This talk will address
the problem of and/or parallelism in logic
programming. We describe a computational model
for and/or parallel execution of logic programs.
The model provides the primitives to describe
and analyze parallel interpreters, emphasizing
the data-flow among conjunctive goals. The
effectiveness of our computational model is
established through its ability to support both
old and new communication paradigms for the
parallel interpretation of logic programs.
Prof. S. Kasif, Department of Computer Science,
University of Maryland, College Park
Host: P. Lucas
------------------------------
Date: 02 Aug 85 15:31:01 EDT (Fri)
From: Emil J. Volcheck <volcheck at UDel-Dewey.ARPA>
To: AIList
Re: Parallel Processing and Economics & Theorem Proving
[Forwarded from AIList by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
Economists use mathematical models to analyze the behavior of
large systems, in fact some of these models are basically simulations
of an open system in which many individuals are making economic decisions.
If someone can prove theorems pertaining to parallel processing on
distributed systems, these results may carry over to economics, and
vice-versa. Does anyone know of research pertaining to this idea, or
does anyone have thoughts about this?
Also -- Does anyone know of a place in the literature about
theorem-proving where proving a theorem is defined as "The unification of
necessary (given) with sufficient (goal) conditions" ? I'd appreciate
your thoughts on this too.
--Emil Volcheck
------------------------------
Date: 13 Aug 1985 1710-CDT
From: SATISH <THATTE%CSL60%ti-csl.csnet@csnet-relay.arpa>
Subject: Parallel algorithms for linear programming
Do you know anything about solving linear programming problems (for
example, using the Simplex method) using a parallel algorithm ?
Any pointers to literature, feedback or your opinions will be greatly
appreciated.
-- Regards, Satish Thatte
Texas Instruments, Dallas
------------------------------
End of PARSYM Digest
********************
∂16-Aug-85 0925 ullman@diablo a random thought before I forget it
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 09:25:25 PDT
Date: Fri, 16 Aug 85 09:18:59 pdt
From: Jeff Ullman <ullman@diablo>
Subject: a random thought before I forget it
To: nail@diablo
Has anyone thought about transformations that convert nonlinear
rules into linear ones, thereby showing that they are in NC?
The canonical example is the transitive closure:
T -> E. T -> TT
which can be rewritten T -> E. T -> ET.
There was a paper in the '82 TOulouse conference that talked
about "Greibach normal form" using this as the example,
but it didn't deal with when the result becomes linear---it was
viewed as a way to eliminate left recursion.
∂16-Aug-85 1010 PAPA@SU-SCORE.ARPA Re: a random thought before I forget it
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 10:10:47 PDT
Received: from SU-SCORE.ARPA by diablo with TCP; Fri, 16 Aug 85 10:04:30 pdt
Date: Fri 16 Aug 85 10:00:32-PDT
From: C. Papadimitriou <PAPA@SU-SCORE.ARPA>
Subject: Re: a random thought before I forget it
To: ullman@SU-AIMVAX.ARPA
Cc: nail@SU-AIMVAX.ARPA
In-Reply-To: Message from "Jeff Ullman <ullman@diablo>" of Fri 16 Aug 85 09:18:59-PDT
Message-Id: <12135617974.33.PAPA@SU-SCORE.ARPA>
Athena Roussou at NTU Athens has thought a little about transforming rules.
She convinced me at some point that, if I remember correctly, the
transitive closure example is essentially the only pattern without
use of auxiliary relations and new rules.
Christos.
-------
∂17-Aug-85 1306 BRAD@SU-CSLI.ARPA System clock
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 17 Aug 85 13:06:24 PDT
Date: Sat 17 Aug 85 13:03:19-PDT
From: Brad Horak <BRAD@SU-CSLI.ARPA>
Subject: System clock
To: folks@SU-CSLI.ARPA
Turing's clock was set to July 17th sometime after 8am Saturday, August 17.
The clock was reset at 12:40 Saturday afternoon. Mail sent during this time
may need to be resent, as the receiving mailer may mark the mail as old.
--Brad
-------
∂18-Aug-85 1216 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa birth announcement
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 18 Aug 85 12:15:54 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Sun 18 Aug 85 12:12:29-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Sun 18 Aug 85 12:12:34-PDT
Received: by wisc-rsch.arpa; Sun, 18 Aug 85 14:00:58 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Sun, 18 Aug 85 10:21:04 cdt
Received: from mitre.ARPA by wisc-crys.arpa; Sun, 18 Aug 85 10:20:58 cdt
Received: by mitre.ARPA (4.12/4.7)
id AA16009; Sun, 18 Aug 85 11:22:20 edt
Message-Id: <8508181522.AA16009@mitre.ARPA>
To: theory@wisc-crys.ARPA
Subject: birth announcement
Date: 18 Aug 85 11:22:05 EDT (Sun)
From: laskowsk@mitre.ARPA
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
We would like to announce the birth of our daughter:
Nicole Marie Jaja
July 28, 1985
8 lbs. 7 oz.
--the proud parents Joseph Jaja (eneevax!joseph @ maryland)
Sharon Laskowski (laskowski @ mitre)
∂18-Aug-85 1505 @SU-SUSHI.ARPA:ANDERSON@SU-SCORE.ARPA Thesis Orals, August 22
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 18 Aug 85 15:05:33 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Sun 18 Aug 85 15:01:46-PDT
Date: Sun 18 Aug 85 15:01:52-PDT
From: Richard Anderson <ANDERSON@SU-SCORE.ARPA>
Subject: Thesis Orals, August 22
To: aflb.all@SU-SCORE.ARPA
Message-ID: <12136197117.16.ANDERSON@SU-SCORE.ARPA>
My thesis orals are next Thursday, August 22, 2:15,
Building 160 (pol sci), room 161K
The title of the talk is:
The Complexity of Parallel Algorithms
-- Richard Anderson
-------
∂18-Aug-85 1535 ACUFF@SUMEX-AIM.ARPA Local BUG-LISPM
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 18 Aug 85 15:35:32 PDT
Date: Sun 18 Aug 85 15:35:11-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Local BUG-LISPM
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12136203185.27.ACUFF@SUMEX-AIM.ARPA>
When there are problems using 3600's, please feel free to send reports
or fixes to BUG-LISPM@SUMEX, and read them from <BBOARD>KSL-BUG-LISPM on
SUMEX. This means you can use the 3600 software to submit bug reports,
as well as conventional mail software. I will read msgs sent to this
mailbox, and respond as soon as possible, though anyone interested is
encouraged to contribute knowledge.
-- Rich
-------
∂19-Aug-85 0948 @MIT-MC.ARPA:Hewitt@MIT-MC.ARPA Prolog will fail as the foundation for AI; so will LOGIC as a PROGRAMMING Language
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 09:48:01 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 AUG 85 12:48:00 EDT
Received: from MIT-XX.ARPA by MIT-OZ via Chaosnet; 19 Aug 85 12:46-EDT
Date: Mon, 19 Aug 1985 12:47 EDT
Message-ID: <HEWITT.12136401984.BABYL@MIT-XX>
Subject: Prolog will fail as the foundation for AI; so will LOGIC as a PROGRAMMING Language
To: phil-sci@MIT-OZ
Sender: HEWITT@MIT-XX
From: Hewitt@MIT-MC.ARPA
CC: Hewitt@MIT-XX, PEREIRA@SRI-AI.ARPA
Date: Saturday, 17 August 1985 13:36-EDT
From: PEREIRA at SRI-AI.ARPA
To: HEWITT at MIT-MC.ARPA
Re: Prolog will fail as the foundation for AI; so will LOGIC as
Carl Hewitt's message is based on several misconceptions:
1. (the least interesting one) All the so-called commercially viable
Prolog systems in Lisp are not really Prolog systems written IN Lisp,
but rather Prolog systems written FOR Lisp machines. Or is it that a
microcode sublanguage or Lisp machine pointer-smashing operations are
part of List as we know it?
Yes. They are DEFINITELY part of Common Lisp as we know it being
implementations of reading and writing operations on record
structures. Such implementation methods are NOT part of Logic as a
Programming language.
Without those machine-level operations,
those Prolog systems would run too slow and use too much memory to be
useful for serious Prolog programming. From the Prolog implementation
point of view, what is important about the Lisp machines is not that
they run Lisp, but that they can be microcoded and have good support
for tagged data types and stack operations.
It is important to many users that they can make use of ALL the software
available to the community and not just be limited to the tiny amount
in Prolog. Furthermore in the future good software will be ported
from stand alone Prolog systems to Prolog implemented on Lisp. However
to good Lisp software will not be able to be ported to the stand
alone Prolog systems.
2. If the decisions (actions) of a system are not determined by its
inputs, the system is nondeterministic. Nondeterminism in a system can
be either an artifact of our incomplete knowledge (or lack of
interest) of the detailed operation of the system; or it can be
``real physical'' nondeterminism. It would take us to far to discuss
whether the second kind of nondeterminism is ``real'' or also an
artifact. In any case, most uses of nondeterminism, say in models of
concurrency, are of the first kind, and can be expressed appropriately
in various temporal/dynamic logics. Admittedly, these are not Prolog,
but then Common Lisp is not Lisp 1.5! (Prolog is 13 years old, Lisp
25).
Yes indeed there is a large problem here that poses fundamental problems
for using Logic as a Programming language to make decisions in Open
Systems.
3. The first logic course dictum ``from a contradiction one can
conclude anything'' is getting in the way. Notice that the dictum says
``can'', not ``must''. There is an enormous difference between things
that are in principle true and things that an agent knows to be true
in a way that can affect its action. An agent might know ``p'' and
``not p'', but it might well never come to infer the dreaded totally
unrelated ``q'' which IN PRINCIPLE follows from the contradiction.
This inference might not happen either because of inference control
mechanisms of the agent (eg. it uses the set-of-support strategy) or
because the agent's logic is just TOO WEAK to conclude anything from a
contradiction (vide Hector Levesque's work in the proceedings of the
last AAAI). In any case, Horn clauses (the basis of Prolog) are too
weak to represent contradictions... :-)
I claim that in practice the contradictions lie close to the surface and
occur in any nontrivial application. Thus the contradictions
pose fundamental problems for using Logic as a Programming Language.
4. The question of whether ``taking action'' fits in a logic paradigm
tends to be answered negatively after an hour's worth of
consideration. If you persist for several years, though, this
question becomes a source of insight on the relations between
knowledge, state and action that is not available to those who started
by dismissing the question after that initial hour. There is just too
much work on logics of knowledge and action in AI and computer science
for me to try to discuss it here. Some of this work has been applied
to logic programming, either in the form of new logic programming
languages based on temporal or dynamic logics or in representations of
temporal reasoning and decision in, say, Prolog.
I have been thinking about the problem for many years having designed
Micro-Planner, the first "procedural embedding of logic" programming
language in 1967. I claim that the problem of taking action poses
fundamental problems for using Logic as a Programming language.
5. It is curious to see someone by implication defend Lisp as a
language for expressing the taking of action!
I claim that current Lisp systems are better than current Prolog
systems for taking action because the only ways to take action in
current Prolog systems are kludges.
We know by now that the
most difficult issue in ``reactive systems'' is not EXPRESSING action,
but rather keeping it under control to prevent unwanted interactions.
In this area, less is REALLY more, and highly complex languages like
Lisp are just not suitable for the formal reasoning about programs
that is needed to help us believe our programs do what we intend. To
those who say ``...but we can keep to a carefully constrained subset
of Lisp, use only message passing for interactions,...'' I will answer
that the history of all large Lisp programs I know (and I think that
is a representative sample) is littered with the brutalized corpses of
constrained programming styles. Anyone who has looked at the current
flavor mechanism in Zetalisp and its use in the window system will
know what I mean...
5. Underlying Carl Hewitt's misconceptions is the old chestnut ``logic
is static, systems are dynamic''.
Note that the above quotation is NOT anything that I said.
Any language, be it first-order
logic or Lisp, is static; it is its USE which is dynamic (changes the
state of communicating agents). A good analogy here is the use of
differential equations to model dynamic systems in classical
mechanics. The differential equations themselves do not say directly
what happens when (they are ``static'' in Hewitt's jargon).
I do not deny that dynamic systems can be DESCRIBED using logic only
that they can be CONTROLLED.
It is
their SOLUTIONS that tell us the sequence of events. Even the
solutions are given as static objects (functions from an open interval
of the reals to some space). Does anyone worry that such equations do
not ``really'' describe the dynamic behavior of a system? Is it not
possible to combine such ``static'' entities with an incremental
solution procedure to build systems that actually control their
(classical mechanical) environment?
I do not believe that the control system can be implemented using Logic
as a Programming language
∂19-Aug-85 1005 ullman@diablo events this week
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 10:04:58 PDT
Date: Mon, 19 Aug 85 09:59:12 pdt
From: Jeff Ullman <ullman@diablo>
Subject: events this week
To: nail@diablo
We'll meet 10AM in 301MJH as usual for our weekly gabfest.
Kathy Morris is going to lead a discussion on the structures
that she has set up to represent the rules in a NAIL! source
program.
We also have a special seminar on Thursday, 8/22 11AM in Rm. 352MJH.
COme find out about the mysterious "APEX" method of processing
logic. A title and abstract are attached.
*************************
Inference by Generating and Structuring Deductive Databases
E. L. Lozinskii
Hebrew Univ.
A strong advantage of bottom-up generating techniques is that they
guarantee finiteness of all inferences in a deductive database system
involving recursive axioms. But a "brute force" generation of answers
to a query would be very inefficient, producing many facts useless
for the query evaluation. An economical generating method is presented,
based on discovering explicit facts relevant to the query and applying
preselected axioms as generating rules. The method is complete,
in the sense that it generates all the existing answers to the query
in a finite time.
An important problem of designing deductive
databases and their structuring is the question of what knowledge
should be represented by explicit facts and what by means of axioms.
A performance-oriented dynamic structuring of databases is proposed,
influenced by the query evaluation method described.
∂19-Aug-85 1516 avg@diablo linear approximations
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 15:16:43 PDT
Date: Mon, 19 Aug 85 15:06:21 pdt
From: Allen VanGelder <avg@diablo>
Subject: linear approximations
To: nail@diablo
Consider the NC program P1 in which q and e are EDB relations:
p(X,Y) :- p(X,Z), q(Z,V), p(V,Y).
p(X,Y) :- e(X,Y).
Apparently the following linear program P2 has the same minimum models:
p(X,Y) :- e(X,Z), q(Z,V), p(V,Y).
p(X,Y) :- e(X,Y).
Proof: Let < denote subset and let P1 stand for "min model of P1", etc.
Clearly P2 < P1. For the other direction, the inductive hypothesis is
that all atoms derivable from P1 in k steps are also derivable from P2.
It is true for k=1. For k > 1, the last step must use rule 1. Say the
specific application is
p(a,b) :- p(a,c), q(c,d), p(d,b).
Then P2 derives p(a,c) and p(d,b) because P1 derives them in fewer than k
steps. It is easy to show that p(a,c) is derivable by P2 if and only if
there is a chain of EDB atoms:
e(a,c0), q(c0,a1), e(a1,c1), q(c1,a2), ... , e(an, c)
(Just use induction on the number of steps P2 requires.)
Therefore P2 derives p(an,b) by means of
p(an,b) :- e(an,c), q(c,d), p(d,b).
Working back down the chain, P2 derives p(a←{n-1}, b), ..., p(a1,b), p(a,b).
QED.
The proof is trivial, but I put it down so we could see what problems
arise in trying to generalize. We can confine ourselves to one recursive
predicate p and one base rule for it, p :- e. I believe these are not
essential restrictions. Now we can consider 3 avenues of generalization:
(1) Multiple recursive rules
(2) Different arrangements of the variables among the subgoals,
leading to different types of joins.
(3) More than 2 recursive subgoals per rule.
Here is P3 to test our mettle:
p(X,Y) :- p(X,Z1), q1(Z1,V1), p(V1, Y).
p(X,Y) :- p(X,Z2), q2(Z2,V2), p(Y, V2).
p(X,Y) :- e(X,Y).
One possibly useful way to rewrite this is to use r(X,Y) = p(Y,X) and try
to make all derivations left-to-right joins. To further this cause we use
q3(X,Y)= q1(Y,X) and q4(X,Y) = q2(Y,X) and f(X,Y) = e(Y,X). We get:
p(X,Y) :- p(X,Z1), q1(Z1,V1), p(V1, Y).
p(X,Y) :- p(X,Z2), q2(Z2,V2), r(V2, Y).
p(X,Y) :- e(X,Y).
r(X,Y) :- r(X,V1), q3(V1,Z1), r(Z1, Y).
r(X,Y) :- p(X,V2), q4(V2,Z2), r(Z2, Y).
r(X,Y) :- f(X,Y).
Because of the regular structure we can omit the arguments and write these
rules as a CFG:
P -> e | P q1 P | P q2 R
R -> f | R q3 R | P q4 R
Beginning a Greibach normal form translation to remove RIGHT recursion
(the opposite HU), we remove R as rightmost symbol.
R -> f | S f
S -> R q3 | P q4 | S R q3 | S P q4
P -> e | P q1 P | P q2 f | P q2 S f
But now we can get rid of R altogether:
P -> e | P q1 P | P q2 f | P q2 S f
S -> f q3 | S f q3 | P q4 | S f q3 | S S f q3 | S P q4
Continue by removing rightmost P:
T -> P q1 | T P q1
P -> e | P q2 f | P q2 S f | T e | T P q2 f | T P q2 S f
S -> f q3 | S f q3 | P q4 | S f q3 | S S f q3 | S P q4
Now it is time to apply the paradigm
"Greibach normal form + mistakes = linear recursion"
I'll start by forgetting S -> S S f q3.
T -> P q1 | T P q1
P -> e | T e | P q2 U f | T P q2 U f
U -> [] | S where [] = "empty"
S -> V | S V
V -> f q3 | P q4
Now with liberal abuse of notation, I'll represent U by the regular
expression (f q3 + P q4)*.
T -> W P q1
P -> W e | W P q2 (f q3 + P q4)* f
W -> [] | T
It looks like W is (P q1)*, and (a+b)* = (a*b*)*, giving:
P -> (P q1)* e | (P q1)* P q2 ((f q3)* (P q4)*)* f
I think this is correct, but can anybody do anything with it?
∂19-Aug-85 1620 @MIT-MC.ARPA:august@JPL-VLSI.ARPA Got to keep trying! Sorry about all the copies.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 16:19:51 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 AUG 85 19:20:32 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 19 Aug 85 19:18-EDT
Received: from JPL-VLSI.ARPA by MIT-MC.ARPA 19 Aug 85 19:19:14 EDT
Received: from vlsidc by VLSIDC with VMS ; Mon, 19 Aug 85 16:19:24 PDT
Date: Mon, 19 Aug 85 16:19:24 PDT
From: august@JPL-VLSI.ARPA
Subject: Got to keep trying! Sorry about all the copies.
To: phil-sci%mit-oz%mit-mc@JPL-VLSI.ARPA, august@JPL-VLSI.ARPA
From: VLSIDC::ST%"" 19-AUG-1985 16:16
To: AUGUST
Subj: Msg of Monday, 19 August 1985 19:15-EDT
Received: from MIT-MC.ARPA by JPL-VLSI.ARPA with INTERNET ; Mon, 19 Aug 85 16:16:24 PDT
Date: Mon, 19 Aug 85 19:15:25 EDT
From: Communications Satellite <COMSAT@MIT-MC.ARPA>
Subject: Msg of Monday, 19 August 1985 19:15-EDT
To: "august@JPL-VLSI.ARPA"@JPL-VLSI.ARPA
Message-ID: <[MIT-MC.ARPA].618302.850819>
============ A copy of your message is being returned, because: ============
"PHIL-SCI-REQUEMIT-OZ" at MIT-MC.ARPA is an unknown recipient.
============ Failed message follows: ============
Received: from JPL-VLSI.ARPA by MIT-MC.ARPA 19 Aug 85 19:14:26 EDT
Received: from vlsidc by VLSIDC with VMS ; Mon, 19 Aug 85 16:14:57 PDT
Date: Mon, 19 Aug 85 16:14:57 PDT
From: august@JPL-VLSI.ARPA
Subject: try again
To: phil-sci-request%mit-oz%mit-mc@JPL-VLSI.ARPA, august@JPL-VLSI.ARPA
From: VLSIDC::AUGUST "Richard B. August" 19-AUG-1985 16:11
To: ST%"request-phil-sci%mit-oz@mit-mc",AUGUST
Subj: Addition to mailing list
Please add me to the Phil-Sci list.
Regards,
Richard
∂19-Aug-85 2011 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #36
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 19:27:36 PDT
Date: Monday, August 19, 1985 9:33AM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #36
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Tuesday, 20 Aug 1985 Volume 3 : Issue 36
Today's Topics:
Query - LP Based Specification Language,
LP Philosophy - Hewett Challenge
----------------------------------------------------------------------
Date: Sat, 10-Aug-85 14:36:30 PDT
From: P. Allen Jensen gatech!gitpyr!allen@UCB-Vax
Subject: Prolog based Software Specification Language
I am trying to find information on Software Specification
Languages written in Prolog. I have looked at two non
procedural description techniques, one based on regular
expressions, the other utilizing a data base approach.
Bibliographic information would be of help. It seems
to me that Prolog would be a good language to use for
developing a software specification language.
-- P. Allen Jensen
------------------------------
Date: Sun, 11-Aug-85 10:34:32 PDT
From: P. Allen Jensen gatech!gitpyr!allen@UCB-Vax
Subject: Program Specification Languages
I am doing some research on Program Specification Languages.
I am aware of only two system currently available:
o - Program Statement Language/Program Statement Analyzer
(PSL/PSA) University of Michigan
o - Software Development System (SDS, SREM)
Ballistic Missile Defense and TRW, Inc.
PSL uses Objects and Relationships to describe a system.
The language allows 22 possible objects and 36 relationships.
These descriptions are then analyzed by PSA for redundancies
or logical inconsistencies. PSA, however, is not
rigorous and therefore cannot provide a mathematically correct
verification of the logical consistency of the specifications.
I am not familiar with SDS, but understand that it is more
extensive than PSL/PSA.
Any further information on currently available products or
research in this area would be appreciated. I am considering
developing a prototype language for specifications in Prolog.
All comments and suggestions are welcome.
-- P. Allen Jensen
------------------------------
Date: Wed, 14 Aug 85 01:03:48 EDT
From: Carl E. Hewitt <HEWITT@MIT-MC.ARPA>
Subject: Prolog will fail as the foundation for AI; so will
[ The following four messages are reprinted from
the Phil-Sci list. -ed ]
Folks,
This list has been rather dormant. To liven things up, I
would like to throw out the following little ticker:
Prolog (like APL before it) will fail as the foundation for
Artificial Intelligence because of competition with Lisp.
There are commercially viable Prolog implementations written
in Lisp but not conversely.
LOGIC as a PROGRAMMING Language will fail as the foundation
for AI because:
1. Logical inference cannot be used to infer the decisions
that need to be taken in open systems because the decisions
are not determined by system inputs.
2. Logic does not cope well with the contradictory knowledge
bases inherent in open systems. It leaves out
counterarguments and debate.
3. Taking action does not fit within the logic paradigm.
------------------------------
Date: Wed 14 Aug 85 10:49:57-PDT
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Challenge Problem
I have long believed that any algorithm developed in a procedural
language could be reformulated more elegantly in a logic language.
This may be true, but I have come to doubt its utility. Restating
an algorithm in nonprocedural form can be a useful exercise, but
does not improve on the procedural nature of the algorithm.
Advocates of logic programming would have a weak case if their
languages were just notations for telling the computer what to do,
step by step.
In order to sharpen my understanding of logic programming, I would
be interested in hearing about logic-based solutions to a problem
that I consider particularly "algorithmic": extraction of connected
components in images. I would like to learn of any logic-based
approach to the problem that would entail neither massive search nor
such extensive procedural embedding as to make the "logic" portion
trivial.
The problem: Assume that you have an array of integers, and are
to identify all maximal connected components -- i.e., all clusters
of identical integers. The integers range from 0 to some known
maximum, with 0 being a special code that connects with the space
"outside" the array. You are free to use any bounded intermediate
data structures. The output is to consist of an array in which
elements of each connected component are marked with the same
integer code, and elements of different components are marked with
different codes. Other outputs (boundary traces, lists of region
adjacencies and inclusion relationships, number of holes per
region, etc.) are desirable but of secondary importance.
I know of several good algorithms for solving this problem. Most
involve an intermediate map or equivalent data structure that records
nonmaximal connected components found during a row-by-row scan,
together with a list of discovered equivalences that can be used to
link these into maximal components. Such algorithms are quite
efficient (aside from having to scan the array completly, in the
worse case, before starting to build the output map). Others involve
visiting (and marking) every point in the array, tracing region
boundaries until they close and then raster scanning to find the
next unvisited point. (This is a reasonable procedure if the
boundary traces are of primary interest.)
Is there any hope that a logic-based language could compile a
[nonalgorithmic] declarative statement of this problem into similar
code, or would the compiler have to be guided by domain knowledge that
essentially supplies it with the right answer? If the latter
is true, in what sense is logic programming the answer to our
current needs?
-- Ken Laws
------------------------------
Date: Wed, 14 Aug 85 10:23:10 cdt
From: Kenneth Forbus Forbus%uiucdcsp@Uiuc
Subject: Prolog will fail as the foundation for AI
(Carl, I wish you had found a fresher topic to re-open the
list with. And doing it right before conference season...)
To equate "prolog" with "logic programing, as Carl & Wayne's
messages comes very close to doing, is somewhat less than
accurate. True, prolog is currently the logic programming
language of choice. True, prolog provides a handy notion
of variable that takes painful effort to build in Lisp.
But prolog really is "Micro-Planner done right", as its
advocates claim, and that is enough to allow most AI people
to tune out prolog because we found out a long time ago that
Micro-Planner isn't what we want.
Prolog suffers from being both too old and too new. It is
too old, in the sense that it has chronological backtracking
built into its roots and the standard versions don't take
into account new ideas (such as TMS'). Yes, of course one
can encode these things in logic and "run them" in Prolog
(If you really believe prolog is "programming in logic" I
have a bridge to sell you). However, you may not get an
answer in the lifetime of the universe, and doing three or
four experiments will have you sitting fruitlessly at the
console long enough to write a fast lisp program to do the
same thing! But prolog is too new, in that it has also not
kept pace with progress in programming environments and
language design. Talking to prolog programmers is a bit
like talking to lisp programmers 10 years ago -- there are
many dialects, often changing rapidly, wild disagreements
on syntax, etc. The days of CommonProlog are likely to be
pretty far off.
Judging the idea of logic programming by prolog is a bit like
judging lisp by Lisp 1.5. I believe that only a tiny fraction
of the interesting ideas which should be encapsulated in a real
logic programming language have been developed. If some venture
capitalist were to ask me into whose pocket should he put $1M to
get a signficant advance in the state of logic programming, I
wouldn't suggest spending it on the prolog community. I'd
probably suggest splitting it between McAllester & de Kleer,
whose ideas on TMS', while rather different, are both far more
interesting and potentially productive ideas than, say, improving
the speed of unification or studying and-parallelism. We simply
don't have enough experience writing and using reasoning languages
yet to either cast our ideas into stone (i.e., adopt prolog and
spend our time optimizing it) OR pass final judgement on the
merits of logic programming.
On logic and action: Why shouldn't Shakey be considered a counter
example to Carl's claim about the impossibility of action in a
system based on logic? Shakey used resolution theorem proving to
decide what to do and other kinds of routines (such as A* search)
to flesh out the details. If the existence of these other routines
is considered sufficient to discount Shakey as a counterexample
then the claim seems rather uninterestingly obvious.
------------------------------
Date: Wed 14 Aug 85 12:07:05-EDT
From: Vijay <Vijay.Saraswat@CMU-CS-C.ARPA>
Subject: On logic programming as a foundation for AI.
This is a response to some of the issues recently raised
by Hewitt in a post to the PHIL-SCI digest. (Phil SCI
Digest, Aug 14).
For the sake of argument, Prolog is probably a `more convenient'
language for writing compilers than Lisp; on the other hand,
the current state of sophistication of Lisp implementations makes
them extremely attractive for developing rapid prototype
implementations. For the near future I see the ideal programming
environment as being a Lisp Machine with a very fast Prolog on it
(If Symbolics Prolog lives up to rumours of 100K Lips that will
do, thank you.) Why would anyone EVER want to write a CommonLisp
interpreter in Prolog? There are much better things to do ...
particularly when you already have CommonLisp and Prolog!
What does this have to do with "being a foundation for AI"?
If he means that "X is a foundation for AI" if X is used by
most people for writing their AI programs, then that is
irrelevant. I would say that "X is a foundation for AI"
if most work being carried out in AI can fit in the theoretical
framework of X. With such a working definition it is rather
doubtful if any one paradigm can be a foundation for AI. But I
would submit that the concept of logic programming is a step
towards reaching such a foundational understanding.
"Logic as a programming language will fail as the foundations
for AI because..."
Let's be careful how we bandy terms around. Logic is not a
programming language. Logic is logic, a formal system. The
first axiom of logic programming (the LOGIC axiom) is that
the definite clause subset of logic has an appealing
interpretation as a programming language, if the process of
SLD-refutation (which is complete for this subset) is taken
as the inference mechansim. In this programming language,
the user has DON'T KNOW CHOICE, i.e. the power of specifying
existential searches. This power is rather unnerving. The
second axiom of logic programming (the CONTROL axiom) is that
it is possible to provide general control mechanisms which can
be exploited by a programmer for controlling the search. This
led to the rise of logic programming languages, which allow,
in general, the programming of incomplete searches, (hence the
handling of non-montonic inference, defaults, inheritance ...).
The most ancient of these is PROLOG, which essentially provided
the control structure of SEQUENTIALITY. The language PROLOG has
something to do with logic of course, but, because of its
incomplete proof procedure, its semantics is best given via
denotational means, rather than logical means. This is the
first corollary of logic programming: a formal understanding of
logic programming languages has to appeal to traditional computer
science techniques for giving semantics to programming languages.
The surprising discovery is that because of the simplicity of the
underlying execution mechanism such semantics are surprisingly
simple: far simpler than semantics for ALGOL, LISP (has anyone
ever attempted a semantics for something like COMMONLISP?),
ACTORS... This has very powerful connotations with respect to
semantically based programming environments, program
transformations, and meta-programming.
There have been more recent languages which have provided other
control features: PARLOG, GHC, Concurrent Prolog and CP[!,|,&],
to name just a few in the main stream of Horn logic programming,
have attempted to also provide don't care choice and parallelism.
To frame it in the current parlance, these languages essentially
provide support for object-oriented programming. While a formal
denotational semantics for the last is still being developed
(the others do not yet have formal semantics), it has already
been demonstrated that it has a surprisingly simple partial
correctness semantics.
More important, these languages demonstrate that while
keeping the LOGIC component more or less identical, it is
possible to achieve a great variety of operational
behaviours by changing the CONTROL component. Hence logic
programming is not a LANGUAGE, it is a PROGRAMMING PARADIGM
encompassing all these operational behaviours.
To sum up, logic programming langauges are not just any
programming languages, at some level, most programs written
in such languages have a declarative interpretation
compatible with a logic system, typically universally quantified
definite clause logic. Logic programming languages are not just
logic systems because their control component plays an important
part. The art of designing logic programming languages is
concerned with maintaining a delicate balance between these two
divergent themes. Even with their control components, logic
programming languages can generally be given simple semantics,
which reflects their underlying conceptual simplicity.
As far as supporting most of the current AI paradigms is concerned,
it should be clear that Definite clause logic supports naturally
the notions of goal-driven backward chaining.
It is my contention (as yet unsupported) that the basic style of
computation provided by Concurrent Prolog and CP[!,|,&] naturally
supports data-driven, forward-chaining inference and also knowledge
structuring a la semantic network based languages, again via the
primary mechanism of message-passing. ("reserach in progress",
though there is an article by Shapiro andd Takeuchi on object
oriented programming in Concurrent Prolog).
Hence I would conclude that, to the extent that logic programming
languages support such programming paradigms, and to the extent
that they themselves have secure theoretical foundations, one can
at least claim that logic programming offers a step towards a
unified understanding of the foundations of (programming paradigms
used in) AI.
Note that I am not saying anything at all about the psychological
plausibility of controlled inference as the essential "problem
solving capability" in intelligent agents.
Let me now discuss three specific poinst raised by Hewitt:
"1. Logical inference cannot be used to infer the decisions that
need to be taken in open systems because the decisions are not
determined by system inputs.
2. Logic does not cope well withthe contradictory knowledge
bases inherent in open systems. It leaves out counterarguments
and debate.
3. Taking action does not fit within the logic paradigm."
Some of these contentions have been made by Hewitt in other
contexts and I still remain as mystified by them as I was then.
Let us keep in mind that we are talking of programming langauges,
albeit peculiar programming languages. How does a LISP function
'take action'? Presumably by doing a (setq foo 'take-action).
How does an OPS-5 program take action? Presumably by executing a
(make task-312 ↑task take-action) on the right hand side of a
production. So also logic programming languages take action by
instantiating a variable to some value. If that variable was
actually implemented as a particular memory cell which is being
monitored by ahard-wired coke-dispenser, then it would 'take
action': deliver a coke bottle.
Presumably what is confusing Hewitt is that in Prolog bindings
can be done on backtracking. But all that is in the programmer's
control! If the programmer intended that the action to be taken
is irrevocable, he would write his axioms in such a fashion that
the binding would not be backtracked over. That is a control
problem!
About contradictory data bases. First let me make the obvious
statement that a certain level of understanding, every set of
definite clause has a model, indeed an infinity of models. Hence
there is no scope for representing contradictory knowledge
directly via axioms in a Horn logic program. So how do logic
programming systems do it? Well you have to PROGRAM IN your
handling of such data. You have to write a program, just as you
would write a program in LISP or ATOLIA which does to this data
what you want to do with it. The axioms you write (the program
you write) will be executed in the fashion determined by the logic
programming language you choose and by the control you provide:
usually this approximates some kind of inferencing. BUt the action
that gets taken when you execute your program depends upon your
program. If you had written your program such that when you
encounter an inconsistency it would print out "The moon is made of
green cheese" and stop, then, if an inconsitency is encountered,
believe it or not, it will print out "The moon is made of green
cheese" and stop. If you wanted to program in counterargumentsd
and debate then go ahead and do that. Logic programming does not
provide "counterarguments and debate" as a primtive concept.
The advantage that you get by writing your program in a logic
programming language is that you can reason about it, you can
(hopefully) prove that when the program encounters an inconsistency
it will print out "The moon is made of greencheese" and terminate.
And because of the simplicity of the programming paradigm that you
are using, your proofs would be relatively simple. If you were
careful in writing your program and in choosing your logic
programming langauge, the answer that you would get would be a
logical consequence of YOUR AXIOMS (program) which of course COULD
HAVE DONE whatever it wanted to to the data.
Hence, while on the face of it Hewitt's statement (2) is true,
it is totally irrelevant.
This also takes care of the argument that "logical inference
cannot be used to infer decisions that need to be taken in open
systems ..." because logical inference is being used to execute
YOUR PROGRAM, which determines how to make those decisions. If
your program is actually an OPS-5 interpreter which acts on the
data that it gets by using a knowledge base of productions, then,
by heavens, YOUR PROGRAM is NOT doing logical inference. Hence
even if Hewitt's contention is correct, it is totally irrelevant.
-- Vijay A. Saraswat
------------------------------
End of PROLOG Digest
********************
∂20-Aug-85 1240 @SU-SUSHI.ARPA:ANDERSON@SU-SCORE.ARPA Complexity Year info
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Aug 85 12:40:21 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Tue 20 Aug 85 12:38:04-PDT
Date: Tue 20 Aug 85 12:38:00-PDT
From: Richard Anderson <ANDERSON@SU-SCORE.ARPA>
Subject: Complexity Year info
To: aflb.local@SU-SCORE.ARPA
Message-ID: <12136695215.9.ANDERSON@SU-SCORE.ARPA>
This year Complexity Year is being held at the Mathematical Sciences
Research Institute (MSRI) at Berkeley. A large number of computer
scientists will be at the institute during the year.
There will be talks on Tuesdays at 2 pm and 4 pm, with a break for
afternoon tea. I will attempt to keep you informed as to what the talks
will be. I will maintain a mailing list of people wanting to know what the
talks will be, so send me a note if you want to be included in the
mailing list.
MSRI is located in the Berkeley hills, just above the Lawrence Hall of
Science. I can provide more complete and more complicated directions on how
to get there.
Professor C. P. Schnorr will be giving a talk this Friday, August 23 at
2 pm in the MSRI Lecture Hall. The title of the talk is:
Polynomial time algorithms for integer relations,
and lattice basis reduction
-- Richard
-------
∂20-Aug-85 2251 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa "Official" FOCS airline
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Aug 85 22:51:21 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Tue 20 Aug 85 22:49:00-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Tue 20 Aug 85 22:49:17-PDT
Received: by wisc-rsch.arpa; Wed, 21 Aug 85 00:35:03 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Tue, 20 Aug 85 18:41:02 cdt
Message-Id: <8508202340.AA04487@wisc-crys.arpa>
Received: from csnet-relay.arpa by wisc-crys.arpa; Tue, 20 Aug 85 18:40:51 cdt
Received: from uoregon by csnet-relay.csnet id ac09844; 20 Aug 85 19:34 EDT
Received: by uo-vax3.UONET (4.12/1.0.uoregon)
id AA01054; Tue, 20 Aug 85 11:17:49 pdt
Date: Tue, 20 Aug 85 11:17:49 pdt
From: Fall Conference Mail <focs%uoregon.csnet@csnet-relay.arpa>
Posted-Date: Tue, 20 Aug 85 11:17:49 pdt
To: theory@WISC-CRYS.ARPA
Subject: "Official" FOCS airline
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
Here are some more details on United Airlines offer to FOCS travelers.
United Airlines has been designated as the "Official Carrier for FOCS '86"
UA will offer special airfares, not available to the general public, when
you attend FOCS and travel between October 18, 1985 and October 26, 1985.
You can obtain a 35% discount from the unrestricted Day Coach fare OR a
15% discount from the Easy Saver fare (requiring a Saturday night stay).
The discounts are available only on United Airlines flights in the
continental U.S. To take advantage of these fares:
1. Call United's Convention Desk toll-free at 800-521-4041, Monday-Friday,
8:30am-8:00pm Eastern time. Your travel agent may make the call.
2. Give the Focs account number 562T.
3. United specialists will provide information and make reservations for
all United flights and fares, including the special FOCS fares.
4. United can arrange to mail tickets to your home or office, or you may
purchase them from your travel agent.
Seats are limited, so call early to ensure availability. Fares are
guaranteed at time of purchase.
------------------------------------------------------------------------------
Please feel free to direct any questions relative to FOCS local arrangements
to focs@uoregon
∂20-Aug-85 2302 ullman@diablo
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 20 Aug 85 23:02:25 PDT
Date: Tue, 20 Aug 85 22:58:36 pdt
From: Jeff Ullman <ullman@diablo>
To: Jskud@diablo, avg@diablo, cohn@diablo, freeman@diablo, karlin@diablo,
kuper@diablo, morris@diablo, nail@diablo, naughton@score, pph@sail,
roy@diablo, trickey@diablo
Here are some more details on United Airlines offer to FOCS travelers.
United Airlines has been designated as the "Official Carrier for FOCS '86"
UA will offer special airfares, not available to the general public, when
you attend FOCS and travel between October 18, 1985 and October 26, 1985.
You can obtain a 35% discount from the unrestricted Day Coach fare OR a
15% discount from the Easy Saver fare (requiring a Saturday night stay).
The discounts are available only on United Airlines flights in the
continental U.S. To take advantage of these fares:
1. Call United's Convention Desk toll-free at 800-521-4041, Monday-Friday,
8:30am-8:00pm Eastern time. Your travel agent may make the call.
2. Give the Focs account number 562T.
3. United specialists will provide information and make reservations for
all United flights and fares, including the special FOCS fares.
4. United can arrange to mail tickets to your home or office, or you may
purchase them from your travel agent.
Seats are limited, so call early to ensure availability. Fares are
guaranteed at time of purchase.
------------------------------------------------------------------------------
Please feel free to direct any questions relative to FOCS local arrangements
to focs@uoregon
∂20-Aug-85 2302 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa Roommates for FOCS
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Aug 85 23:02:38 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Tue 20 Aug 85 22:49:47-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Tue 20 Aug 85 22:50:02-PDT
Received: by wisc-rsch.arpa; Wed, 21 Aug 85 00:35:47 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Tue, 20 Aug 85 18:41:48 cdt
Message-Id: <8508202341.AA04494@wisc-crys.arpa>
Received: from csnet-relay.arpa by wisc-crys.arpa; Tue, 20 Aug 85 18:41:39 cdt
Received: from uoregon by csnet-relay.csnet id af09844; 20 Aug 85 19:35 EDT
Received: by uo-vax3.UONET (4.12/1.0.uoregon)
id AA02160; Tue, 20 Aug 85 13:25:58 pdt
Date: Tue, 20 Aug 85 13:25:58 pdt
From: Fall Conference Mail <focs%uoregon.csnet@csnet-relay.arpa>
Posted-Date: Tue, 20 Aug 85 13:25:58 pdt
To: theory@WISC-CRYS.ARPA
Subject: Roommates for FOCS
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
Looking for a roommate for FOCS meeting?
We are maintaining a listing of those looking for person(s) with whom to
share a hotel room at FOCS. Send following information to focs@uoregon
Name ..................................................
Institution ...........................................
Phone number ..........................................
Electronic address ....................................
Student [ ] Non-student [ ]
Desired number of room occupants (2,3,4) .......
Note: To obtain special room discount for students, all occupants must be
full-time students.
We shall mail complete listing to all those on list twice a week. We leave it
to individuals to contact one another. Please send us a note when you have
found roommates so that we can remove your name from list.
∂21-Aug-85 0912 EMMA@SU-CSLI.ARPA Ventura Hall and air conditioning
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 21 Aug 85 09:11:58 PDT
Date: Wed 21 Aug 85 09:04:27-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Ventura Hall and air conditioning
To: bboard@SU-CSLI.ARPA
cc: folks@SU-CSLI.ARPA
Tel: 497-3479
The air conditioning in Ventura Hall has been turned off TODAY
(August 21).
Please make sure that your dandelions do not suffer from heat stroke;
turn them off when the room gets too warm.
This message does not apply to the trailers.
Any questions should be sent to Jamie@csli.
-------
∂21-Aug-85 0925 ullman@diablo don't forget
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 21 Aug 85 09:25:27 PDT
Date: Wed, 21 Aug 85 09:20:20 pdt
From: Jeff Ullman <ullman@diablo>
Subject: don't forget
To: nail@diablo
meeting 10AM today, 301 MJH
Lozinskii talk, 11AM tomorrow (Thursday), 352 MJH
Shapiro talk, 9AM Monday 8/26, 352 MJH
∂21-Aug-85 1158 STUCKY@SU-CSLI.ARPA D-lion Users
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 21 Aug 85 11:58:21 PDT
Date: Wed 21 Aug 85 11:50:28-PDT
From: Susan Stucky <Stucky@SU-CSLI.ARPA>
Subject: D-lion Users
To: folks@SU-CSLI.ARPA
cc: consultants@SU-CSLI.ARPA
Dear All,
Since many of us are at different sites, the usual method for
disseminating information about machines (i.e., walking down the hall
and asking) isn't available. And then, much of the information I know
of, at least, of is at the level of hearsay. For instance, rumor has it
that Kris Halvorsen has a program that takes LaTex files and translates
them into Tedit files (or is it the other way around??). And I notice
other people's screens and wonder where the program is that does THAT.
Anyway, Jon and I thought a D-lion users fest was in order. We suggest
an informal meeting, in the Trailer Dandelion room this next Tuesday,
the 27th at 1:30 p.m., say, for an hour and a half or so. Though we
hope we can ask of the experts all our naive questions, we thought too
that the experts at various sites might have something to share with
each other.
Bring ideas and questions, in particular, ideas and questions for
across-site problems. Getting files from one machine to another. From
one editor to another. We hope you'll come.
-Susan
-------
∂21-Aug-85 1658 ullman@diablo paper received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 21 Aug 85 16:58:13 PDT
Date: Wed, 21 Aug 85 16:52:22 pdt
From: Jeff Ullman <ullman@diablo>
Subject: paper received
To: nail@diablo
Anyone like to see: "LOGIN: a logic programming language with
built-in inheritance" by H. Ait-Kaci and R. Nasr?
∂21-Aug-85 1736 EMMA@SU-CSLI.ARPA Newsletter August 22, No. 42
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 21 Aug 85 17:36:08 PDT
Date: Wed 21 Aug 85 17:22:48-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter August 22, No. 42
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
August 22, 1985 Stanford Vol. 2, No. 42
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, August 29, 1985
12 noon TINLunch
Ventura Hall ``A Unified Indexical Analysis of ``same'' and
Conference Room ``different'': A Response to Stump and Carlson''
by David Dowty
Discussion led by Mats Rooth
(Abstract on page 1)
2:15 p.m. CSLI Talk
Ventura Hall No talk this week
Conference Room
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
ANNOUNCEMENTS
No activities have been scheduled for this Thursday, August 22. Next
week, TINLunch will resume.
←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S TINLUNCH
``A Unified Indexical Analysis of ``same'' and ``different'':
A Response to Stump and Carlson''
Stump's ``A GPSG Fragment for `Dependent Nominals' '' is concerned
with sentences such as
``Mary saw ``Amadeus,'' but John saw a different movie.''
and
``Every student saw a different movie.''
where the interpretation of ``different movie'' is said to be
dependent on the interpretation of another NP in the sentence or
discourse. Stump's analysis involves quantifier storage; Dowty
criticizes some of the data which motivated this approach, and
proposes an indexical or contextual analysis which posits a number of
free variables in the interpretaton of ``same'' and ``different,'' the
interpretation of which is determined by context. In the second
example above, the interpretation of ``different'' includes a free
variable which is bound by the quantifier ``every student.''
--Mats Rooth
!
Page 2 CSLI Newsletter August 22, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
CSLI WORKSHOP ON GERMAN GRAMMAR
On Monday, August 26, and Tuesday, August 27, a small and rather
informal workshop on problems of German syntax and semantics will be
held at CSLI.
The event was not planned as a conference-style workshop with
fixed-length papers, restricted discussion periods and a large
non-participating audience. The goal is rather to present affiliates
and visitors of CSLI who have worked on different theoretically
interesting aspects of German with an opportunity to learn about each
other's work and to get feedback on their own results. We consider
the mix of syntacticians and semanticists among the participants
especially fortunate for the success of the workshop.
Drop-in participants are welcome but are forwarned not to rely too
much on the announced schedule since talks and discussions may
overrun. On both days, participants will be invited to a simple lunch
on the trailer patio.
Monday morning 9-12:
David Perlmutter On German Causatives
(UCSD)
Mark Johnson Constituent Structure of the
(Stanford and CSLI) German VP
Hans Uszkoreit Ordering Principles
(SRI and CSLI)
Lunch on the patio
Monday afternoon 1:30:
John Nerbonne Tense and Temporal Adverbs
(HP and CSLI)
After John's talk, interested participants will be given a brief
overview over projects on German in the area of computational
linguistics. Guenter Goerz (U. Erlangen), Manfred Pinkal (U.
Duesseldorf), Uwe Reyle (U. Stuttgart), and Hans Uszkoreit (SRI and
CSLI) will give 10 minute talks on recent and current projects such as
HAM-ANS, KIT, METAL, PLIDIS, EVAR, SUSY, the Stuttgart LFG
implementation, GPSG in Berlin.
Tuesday morning 9-12:
Godehard Link Generalized Quantifiers and Plural:
(U. Muenchen and CSLI) The case of German 'je' (each)
Dietmar Zaefferer Bare Plurals and Naked Relatives:
(U. Muenchen and CSLI) Semantics of German wh-constructions
Manfred Pinkal Syntactic and Semantic Gender
(U. Duesseldorf)
Lunch on the patio
Departure of the participants to their offices
!
Page 3 CSLI Newsletter August 22, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
``Logophoricity: SELF and SOURCE in Discourse and Morphology''
Summary of the meeting on Thursday, August 15
Peter Sells gave a presentation on the notion of ``logophoricity''
that is grammatically expressed in many languages, and proposed that
there are more primitive notions of SELF and SOURCE in terms of which
logophoric domains are created and perpetuated. He proposed that the
grammatical conditions on the antecedent of the Japanese reflexive
`zibun' are that:
(a) its antecedent is a grammatical subject, or
(b) its antecedent realises the SELF of the discourse
The SELF may be realised in two ways, either concomitant with the
SOURCE of a verb of communication, as with `Max' in ``Mary heard from
Max that ...'' or ``Max said that ....'' Alternatively, the SOURCE
may be the external speaker, as with the `psychological' predicates,
such as ``That so-and-so distressed Max;'' again `Max' realises the
SELF here. Intuitively, psychological predicates are those predicates
with which an external speaker says something about a mental state of
a sentence-internal protagonist. A simple notion of logophoricity
cannot distinguish these two cases.
A framework for representing these constructs was given, in terms
of the Discourse Representation Theory developed by Kamp, and various
differences between the communicational and psychological predicates
were discussed.
There was also discussion of the English prefix ``self-,'' as in
``self-confidence,'' which also gives evidence in favor of the
constructs proposed by Sells. In particular, nouns like
``self-deception'' give a clear indication that the speaker is
classifying the mental state of some other person. --Peter Sells
-------
∂21-Aug-85 2018 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:Robert←S.←Printis.osbunorth@Xerox.ARPA Re: Complexity Year info
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 21 Aug 85 20:17:55 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 21 Aug 85 20:13:04-PDT
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Aug 85 20:13:19-PDT
Received: from Salvador.ms by ArpaGateway.ms ; 21 AUG 85 20:15:11 PDT
Sender: "Robert S. Printis.osbunorth"@Xerox.ARPA
Date: 21 Aug 85 20:14:04 PDT (Wednesday)
Subject: Re: Complexity Year info
From: Printis.osbunorth@Xerox.ARPA
To: ANDERSON@SU-SCORE.Arpa
cc: aflb.local@SU-SCORE.Arpa
In-Reply-to: ANDERSON%SU-SCORE:ARPA:Xerox's message of 20-Aug-85
22:00:10
Message-ID: <850821-201511-4020@Xerox>
Please add my name to the distribution list. Thanks,
Bob
∂22-Aug-85 1609 MARJORIE@SU-CSLI.ARPA phone lines
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 22 Aug 85 16:08:53 PDT
Date: Thu 22 Aug 85 16:04:36-PDT
From: Marjorie Maxwell <MARJORIE@SU-CSLI.ARPA>
Subject: phone lines
To: folks@SU-CSLI.ARPA
This is to inform everyone of our change of phone lines as there seems
to be some confusion. Rich Cower's line is now 1909. The programmers/
consulants now share 1932. Brad Horak has 2607, Clay Andres 5565, Joe
Zingheim 2658, and I remain at 9030.
Marj
-------
∂22-Aug-85 1651 JAMIE@SU-CSLI.ARPA security
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 22 Aug 85 16:51:40 PDT
Date: Thu 22 Aug 85 16:45:17-PDT
From: Jamie Marks <JAMIE@SU-CSLI.ARPA>
Subject: security
To: folks@SU-CSLI.ARPA
Two people recently reported lost belongings. I feel I ought to warn
you to be careful about locking up, and about leaving purses, briefcases,
packs, etc. out in the open when you're not in the office.
Please let me know if other things are missing.
- Jamie
-------
∂22-Aug-85 2229 JAMIE@SU-CSLI.ARPA security
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 22 Aug 85 22:29:00 PDT
Date: Thu 22 Aug 85 17:24:47-PDT
From: Jamie Marks <JAMIE@SU-CSLI.ARPA>
Subject: security
To: folks@SU-CSLI.ARPA
I should have worded my previous message more strongly. Here's the text of a
message I just received:
Both thefts were of things that WERE locked up. It's
misleading, therefore, to warn people to lock up and
not leave things in the open. They should be warned not
to leave any valuables in their offices overnight.
Once again, please let me know if anything is missing.
- Jamie
-------
∂23-Aug-85 0905 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa Messages to SIAM
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 23 Aug 85 09:05:05 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Fri 23 Aug 85 08:59:34-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Fri 23 Aug 85 08:53:56-PDT
Received: by wisc-rsch.arpa; Thu, 22 Aug 85 20:52:03 cdt
Received: from SU-SCORE.ARPA by wisc-rsch.arpa; Thu, 22 Aug 85 18:27:33 cdt
Date: Thu 22 Aug 85 16:25:14-PDT
From: Gene Golub <GOLUB@SU-SCORE.ARPA>
Subject: Messages to SIAM
To: udi@WISC-RSCH.ARPA
Message-Id: <12137260870.24.GOLUB@SU-SCORE.ARPA>
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
It is now possible to correspond directly by e-mail to SIAM. Correspondence
concerning manuscripts, meetings, dues, etc can be sent to SIAM@SCORE.
Gene Golub
President,SIAM
-------
∂25-Aug-85 0130 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #13
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 25 Aug 85 01:30:49 PDT
Date: 25 Aug 85 0107-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #13
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Sunday, 25 Aug 1985 Volume 1 : Issue 13
Today's Topics:
Query: IBM GF11
Parallel algorithms for linear programming
Symbolic computation
----------------------------------------------------------------------
[Your moderator will be away from his desk for a couple of weeks.
Submissions and requests will be buffered until September 8. If
anyone has summaries of or comments on recent conferences relevant to
PARSYM (e.g., IJCAI or the Parallel Computing conference), please send
them in. I am sure that many readers would be interested. -- BD]
Date: Sat, 17 Aug 1985 07:44 EDT
Sender: GZT.TDF%MIT-OZ@MIT-MC.ARPA
From: "David D. Story" <FTD%MIT-OZ @ MIT-MC.ARPA>
Subject: IBM GF11
Has anyone out there looked at SIGARCH proceeding of last month. I
was wondering what comments might be found on IBM's GF11. I heard of
this machine years ago. I thought at that time it was for a group of
problems General Foods had taken to the Yorktown Group.
I see that they have added some new micro-code features resembling
Hewitt's Actors and Semantic Massage for a society of experts. Though
I dunno as of yet what is happening with AI at Yorktown it seems
they've tried to get this under the hood. If the machine was meant
for the task of computing chromodynamics seems to me that the word
size would have been re-engineered since there is no mention of double
or quad wording in the article. Whatta think ?
Dave
------------------------------
Date: Friday, 16 August 1985 14:59-PDT
From: Deepak D. Sherlekar <deepak at maryland>
To: PARSYM-REQUEST at SUMEX-AIM
Re: Parallel Algorithm for Linear Programming.
Linear Programming is P-complete. There is strong evidence suggesting
that P-Complete problems are unlikely to have fast parallel solutions.
By 'fast' is meant an algorithm that runs in time O((logn)↑k) for some
fixed k on a shared memory parallel random access machine (PRAM) using
polynomial number of processors. Some references to literature on
P-Complete problems and the theory of synchronous parallel algorithms
that I could find/remember readily are:
1. A.K. Chandra, D.C. Kozen and L.J. Stockmeyer, "Alternation", JACM, '81.
2. S.A. Cook, "Towards a Complexity Theory of Synchronous Parallel
Computation", (U of Toronto TR??).
3. D. Dobkin, R. Lipton and S. Reiss, "Linear Programming is P-Complete",
in (same authors) "Excursions into Geometry", Rept. No. 71, Dept.
of Computer Sc., Yale U.
4. M.R. Garey and D.S. Johnson, "Computers and Intractability: A Guide
to the Theory of NP-Completeness", Chapter 7.6.
5. L.M. Goldschlager, "Synchronous Parallel Computation", Ph.D. thesis,
U. of Toronto. See also Proc. 10th STOC and some '82 JACM.
-- Deepak
------------------------------
Date: Wed, 21 Aug 85 12:41:54 BST
From: Fitch@ucl-cs.arpa
Subject: Symbolic Computation
Guy Steele has not got it right with his example of rings, fields and
groups. I compute over a field (of rational polynomials), and this is
normally considered symbolic.
John Fitch
------------------------------
End of PARSYM Digest
********************
∂25-Aug-85 1031 DAVIES@SUMEX-AIM.ARPA Vacation
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 25 Aug 85 10:31:07 PDT
Date: Sun, 25 Aug 1985 10:29 PDT
Message-ID: <DAVIES.12137982517.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: Vacation
cc: Davies@SUMEX-AIM.ARPA
I'll be gone on vacation for the next two weeks. I'm asking Jim Rice
to look after weekly meetings, if there are any. See you in
September.
-- Byron
∂26-Aug-85 0059 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #36
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Aug 85 00:57:31 PDT
Date: Monday, August 19, 1985 9:33AM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #36
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Tuesday, 20 Aug 1985 Volume 3 : Issue 36
Today's Topics:
Query - LP Based Specification Language,
LP Philosophy - Hewett Challenge
----------------------------------------------------------------------
Date: Sat, 10-Aug-85 14:36:30 PDT
From: P. Allen Jensen gatech!gitpyr!allen@UCB-Vax
Subject: Prolog based Software Specification Language
I am trying to find information on Software Specification
Languages written in Prolog. I have looked at two non
procedural description techniques, one based on regular
expressions, the other utilizing a data base approach.
Bibliographic information would be of help. It seems
to me that Prolog would be a good language to use for
developing a software specification language.
-- P. Allen Jensen
------------------------------
Date: Sun, 11-Aug-85 10:34:32 PDT
From: P. Allen Jensen gatech!gitpyr!allen@UCB-Vax
Subject: Program Specification Languages
I am doing some research on Program Specification Languages.
I am aware of only two system currently available:
o - Program Statement Language/Program Statement Analyzer
(PSL/PSA) University of Michigan
o - Software Development System (SDS, SREM)
Ballistic Missile Defense and TRW, Inc.
PSL uses Objects and Relationships to describe a system.
The language allows 22 possible objects and 36 relationships.
These descriptions are then analyzed by PSA for redundancies
or logical inconsistencies. PSA, however, is not
rigorous and therefore cannot provide a mathematically correct
verification of the logical consistency of the specifications.
I am not familiar with SDS, but understand that it is more
extensive than PSL/PSA.
Any further information on currently available products or
research in this area would be appreciated. I am considering
developing a prototype language for specifications in Prolog.
All comments and suggestions are welcome.
-- P. Allen Jensen
------------------------------
Date: Wed, 14 Aug 85 01:03:48 EDT
From: Carl E. Hewitt <HEWITT@MIT-MC.ARPA>
Subject: Prolog will fail as the foundation for AI; so will
[ The following four messages are reprinted from
the Phil-Sci list. -ed ]
Folks,
This list has been rather dormant. To liven things up, I
would like to throw out the following little ticker:
Prolog (like APL before it) will fail as the foundation for
Artificial Intelligence because of competition with Lisp.
There are commercially viable Prolog implementations written
in Lisp but not conversely.
LOGIC as a PROGRAMMING Language will fail as the foundation
for AI because:
1. Logical inference cannot be used to infer the decisions
that need to be taken in open systems because the decisions
are not determined by system inputs.
2. Logic does not cope well with the contradictory knowledge
bases inherent in open systems. It leaves out
counterarguments and debate.
3. Taking action does not fit within the logic paradigm.
------------------------------
Date: Wed 14 Aug 85 10:49:57-PDT
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Challenge Problem
I have long believed that any algorithm developed in a procedural
language could be reformulated more elegantly in a logic language.
This may be true, but I have come to doubt its utility. Restating
an algorithm in nonprocedural form can be a useful exercise, but
does not improve on the procedural nature of the algorithm.
Advocates of logic programming would have a weak case if their
languages were just notations for telling the computer what to do,
step by step.
In order to sharpen my understanding of logic programming, I would
be interested in hearing about logic-based solutions to a problem
that I consider particularly "algorithmic": extraction of connected
components in images. I would like to learn of any logic-based
approach to the problem that would entail neither massive search nor
such extensive procedural embedding as to make the "logic" portion
trivial.
The problem: Assume that you have an array of integers, and are
to identify all maximal connected components -- i.e., all clusters
of identical integers. The integers range from 0 to some known
maximum, with 0 being a special code that connects with the space
"outside" the array. You are free to use any bounded intermediate
data structures. The output is to consist of an array in which
elements of each connected component are marked with the same
integer code, and elements of different components are marked with
different codes. Other outputs (boundary traces, lists of region
adjacencies and inclusion relationships, number of holes per
region, etc.) are desirable but of secondary importance.
I know of several good algorithms for solving this problem. Most
involve an intermediate map or equivalent data structure that records
nonmaximal connected components found during a row-by-row scan,
together with a list of discovered equivalences that can be used to
link these into maximal components. Such algorithms are quite
efficient (aside from having to scan the array completly, in the
worse case, before starting to build the output map). Others involve
visiting (and marking) every point in the array, tracing region
boundaries until they close and then raster scanning to find the
next unvisited point. (This is a reasonable procedure if the
boundary traces are of primary interest.)
Is there any hope that a logic-based language could compile a
[nonalgorithmic] declarative statement of this problem into similar
code, or would the compiler have to be guided by domain knowledge that
essentially supplies it with the right answer? If the latter
is true, in what sense is logic programming the answer to our
current needs?
-- Ken Laws
------------------------------
Date: Wed, 14 Aug 85 10:23:10 cdt
From: Kenneth Forbus Forbus%uiucdcsp@Uiuc
Subject: Prolog will fail as the foundation for AI
(Carl, I wish you had found a fresher topic to re-open the
list with. And doing it right before conference season...)
To equate "prolog" with "logic programing, as Carl & Wayne's
messages comes very close to doing, is somewhat less than
accurate. True, prolog is currently the logic programming
language of choice. True, prolog provides a handy notion
of variable that takes painful effort to build in Lisp.
But prolog really is "Micro-Planner done right", as its
advocates claim, and that is enough to allow most AI people
to tune out prolog because we found out a long time ago that
Micro-Planner isn't what we want.
Prolog suffers from being both too old and too new. It is
too old, in the sense that it has chronological backtracking
built into its roots and the standard versions don't take
into account new ideas (such as TMS'). Yes, of course one
can encode these things in logic and "run them" in Prolog
(If you really believe prolog is "programming in logic" I
have a bridge to sell you). However, you may not get an
answer in the lifetime of the universe, and doing three or
four experiments will have you sitting fruitlessly at the
console long enough to write a fast lisp program to do the
same thing! But prolog is too new, in that it has also not
kept pace with progress in programming environments and
language design. Talking to prolog programmers is a bit
like talking to lisp programmers 10 years ago -- there are
many dialects, often changing rapidly, wild disagreements
on syntax, etc. The days of CommonProlog are likely to be
pretty far off.
Judging the idea of logic programming by prolog is a bit like
judging lisp by Lisp 1.5. I believe that only a tiny fraction
of the interesting ideas which should be encapsulated in a real
logic programming language have been developed. If some venture
capitalist were to ask me into whose pocket should he put $1M to
get a signficant advance in the state of logic programming, I
wouldn't suggest spending it on the prolog community. I'd
probably suggest splitting it between McAllester & de Kleer,
whose ideas on TMS', while rather different, are both far more
interesting and potentially productive ideas than, say, improving
the speed of unification or studying and-parallelism. We simply
don't have enough experience writing and using reasoning languages
yet to either cast our ideas into stone (i.e., adopt prolog and
spend our time optimizing it) OR pass final judgement on the
merits of logic programming.
On logic and action: Why shouldn't Shakey be considered a counter
example to Carl's claim about the impossibility of action in a
system based on logic? Shakey used resolution theorem proving to
decide what to do and other kinds of routines (such as A* search)
to flesh out the details. If the existence of these other routines
is considered sufficient to discount Shakey as a counterexample
then the claim seems rather uninterestingly obvious.
------------------------------
Date: Wed 14 Aug 85 12:07:05-EDT
From: Vijay <Vijay.Saraswat@CMU-CS-C.ARPA>
Subject: On logic programming as a foundation for AI.
This is a response to some of the issues recently raised
by Hewitt in a post to the PHIL-SCI digest. (Phil SCI
Digest, Aug 14).
For the sake of argument, Prolog is probably a `more convenient'
language for writing compilers than Lisp; on the other hand,
the current state of sophistication of Lisp implementations makes
them extremely attractive for developing rapid prototype
implementations. For the near future I see the ideal programming
environment as being a Lisp Machine with a very fast Prolog on it
(If Symbolics Prolog lives up to rumours of 100K Lips that will
do, thank you.) Why would anyone EVER want to write a CommonLisp
interpreter in Prolog? There are much better things to do ...
particularly when you already have CommonLisp and Prolog!
What does this have to do with "being a foundation for AI"?
If he means that "X is a foundation for AI" if X is used by
most people for writing their AI programs, then that is
irrelevant. I would say that "X is a foundation for AI"
if most work being carried out in AI can fit in the theoretical
framework of X. With such a working definition it is rather
doubtful if any one paradigm can be a foundation for AI. But I
would submit that the concept of logic programming is a step
towards reaching such a foundational understanding.
"Logic as a programming language will fail as the foundations
for AI because..."
Let's be careful how we bandy terms around. Logic is not a
programming language. Logic is logic, a formal system. The
first axiom of logic programming (the LOGIC axiom) is that
the definite clause subset of logic has an appealing
interpretation as a programming language, if the process of
SLD-refutation (which is complete for this subset) is taken
as the inference mechansim. In this programming language,
the user has DON'T KNOW CHOICE, i.e. the power of specifying
existential searches. This power is rather unnerving. The
second axiom of logic programming (the CONTROL axiom) is that
it is possible to provide general control mechanisms which can
be exploited by a programmer for controlling the search. This
led to the rise of logic programming languages, which allow,
in general, the programming of incomplete searches, (hence the
handling of non-montonic inference, defaults, inheritance ...).
The most ancient of these is PROLOG, which essentially provided
the control structure of SEQUENTIALITY. The language PROLOG has
something to do with logic of course, but, because of its
incomplete proof procedure, its semantics is best given via
denotational means, rather than logical means. This is the
first corollary of logic programming: a formal understanding of
logic programming languages has to appeal to traditional computer
science techniques for giving semantics to programming languages.
The surprising discovery is that because of the simplicity of the
underlying execution mechanism such semantics are surprisingly
simple: far simpler than semantics for ALGOL, LISP (has anyone
ever attempted a semantics for something like COMMONLISP?),
ACTORS... This has very powerful connotations with respect to
semantically based programming environments, program
transformations, and meta-programming.
There have been more recent languages which have provided other
control features: PARLOG, GHC, Concurrent Prolog and CP[!,|,&],
to name just a few in the main stream of Horn logic programming,
have attempted to also provide don't care choice and parallelism.
To frame it in the current parlance, these languages essentially
provide support for object-oriented programming. While a formal
denotational semantics for the last is still being developed
(the others do not yet have formal semantics), it has already
been demonstrated that it has a surprisingly simple partial
correctness semantics.
More important, these languages demonstrate that while
keeping the LOGIC component more or less identical, it is
possible to achieve a great variety of operational
behaviours by changing the CONTROL component. Hence logic
programming is not a LANGUAGE, it is a PROGRAMMING PARADIGM
encompassing all these operational behaviours.
To sum up, logic programming langauges are not just any
programming languages, at some level, most programs written
in such languages have a declarative interpretation
compatible with a logic system, typically universally quantified
definite clause logic. Logic programming languages are not just
logic systems because their control component plays an important
part. The art of designing logic programming languages is
concerned with maintaining a delicate balance between these two
divergent themes. Even with their control components, logic
programming languages can generally be given simple semantics,
which reflects their underlying conceptual simplicity.
As far as supporting most of the current AI paradigms is concerned,
it should be clear that Definite clause logic supports naturally
the notions of goal-driven backward chaining.
It is my contention (as yet unsupported) that the basic style of
computation provided by Concurrent Prolog and CP[!,|,&] naturally
supports data-driven, forward-chaining inference and also knowledge
structuring a la semantic network based languages, again via the
primary mechanism of message-passing. ("reserach in progress",
though there is an article by Shapiro andd Takeuchi on object
oriented programming in Concurrent Prolog).
Hence I would conclude that, to the extent that logic programming
languages support such programming paradigms, and to the extent
that they themselves have secure theoretical foundations, one can
at least claim that logic programming offers a step towards a
unified understanding of the foundations of (programming paradigms
used in) AI.
Note that I am not saying anything at all about the psychological
plausibility of controlled inference as the essential "problem
solving capability" in intelligent agents.
Let me now discuss three specific poinst raised by Hewitt:
"1. Logical inference cannot be used to infer the decisions that
need to be taken in open systems because the decisions are not
determined by system inputs.
2. Logic does not cope well withthe contradictory knowledge
bases inherent in open systems. It leaves out counterarguments
and debate.
3. Taking action does not fit within the logic paradigm."
Some of these contentions have been made by Hewitt in other
contexts and I still remain as mystified by them as I was then.
Let us keep in mind that we are talking of programming langauges,
albeit peculiar programming languages. How does a LISP function
'take action'? Presumably by doing a (setq foo 'take-action).
How does an OPS-5 program take action? Presumably by executing a
(make task-312 ↑task take-action) on the right hand side of a
production. So also logic programming languages take action by
instantiating a variable to some value. If that variable was
actually implemented as a particular memory cell which is being
monitored by ahard-wired coke-dispenser, then it would 'take
action': deliver a coke bottle.
Presumably what is confusing Hewitt is that in Prolog bindings
can be done on backtracking. But all that is in the programmer's
control! If the programmer intended that the action to be taken
is irrevocable, he would write his axioms in such a fashion that
the binding would not be backtracked over. That is a control
problem!
About contradictory data bases. First let me make the obvious
statement that a certain level of understanding, every set of
definite clause has a model, indeed an infinity of models. Hence
there is no scope for representing contradictory knowledge
directly via axioms in a Horn logic program. So how do logic
programming systems do it? Well you have to PROGRAM IN your
handling of such data. You have to write a program, just as you
would write a program in LISP or ATOLIA which does to this data
what you want to do with it. The axioms you write (the program
you write) will be executed in the fashion determined by the logic
programming language you choose and by the control you provide:
usually this approximates some kind of inferencing. BUt the action
that gets taken when you execute your program depends upon your
program. If you had written your program such that when you
encounter an inconsistency it would print out "The moon is made of
green cheese" and stop, then, if an inconsitency is encountered,
believe it or not, it will print out "The moon is made of green
cheese" and stop. If you wanted to program in counterargumentsd
and debate then go ahead and do that. Logic programming does not
provide "counterarguments and debate" as a primtive concept.
The advantage that you get by writing your program in a logic
programming language is that you can reason about it, you can
(hopefully) prove that when the program encounters an inconsistency
it will print out "The moon is made of greencheese" and terminate.
And because of the simplicity of the programming paradigm that you
are using, your proofs would be relatively simple. If you were
careful in writing your program and in choosing your logic
programming langauge, the answer that you would get would be a
logical consequence of YOUR AXIOMS (program) which of course COULD
HAVE DONE whatever it wanted to to the data.
Hence, while on the face of it Hewitt's statement (2) is true,
it is totally irrelevant.
This also takes care of the argument that "logical inference
cannot be used to infer decisions that need to be taken in open
systems ..." because logical inference is being used to execute
YOUR PROGRAM, which determines how to make those decisions. If
your program is actually an OPS-5 interpreter which acts on the
data that it gets by using a knowledge base of productions, then,
by heavens, YOUR PROGRAM is NOT doing logical inference. Hence
even if Hewitt's contention is correct, it is totally irrelevant.
-- Vijay A. Saraswat
------------------------------
End of PROLOG Digest
********************
∂26-Aug-85 0845 EMMA@SU-CSLI.ARPA Mailing lists
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 26 Aug 85 08:45:48 PDT
Date: Mon 26 Aug 85 08:39:52-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Mailing lists
To: folks@SU-CSLI.ARPA
Tel: 497-3479
The old area mailing lists (f1, f2, c1, p1, nlinterest...) except
Pinterest have been discontinued. I should have the new project
mailing lists working soon.
-Emma
-------
∂26-Aug-85 1033 ACUFF@SUMEX-AIM.ARPA Explorer
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 26 Aug 85 10:33:16 PDT
Date: Mon 26 Aug 85 10:30:50-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Explorer
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12138244931.61.ACUFF@SUMEX-AIM.ARPA>
We are now the proud owners of a TI Explorer, the first a many. It
is currently in the vestibule of Whelan A-1105. The manuals for it
are located above the DLion in the cubicle next to the Explorer.
Power it up by pressing the round button on the processor unit on the
floor to the right of the display. When you are done, and if it seems
unlikely that anyone else will be using the machine for a while, run
(si:shutdown), and then turn off the processor. Leave the display
powered up. It currently has only Chaos network capability, so you
can get to files on the Whelan Symbolics machines, but not to other
Stanford hosts. This should be remedied by mid September.
Please send questions, problems, or bugs to me. My office is right
next to the machine, so this should be particularly easy. Note that
this is a fairly new machine, so there are likely to be problems -->
save your work frequently.
-- Rich
-------
∂26-Aug-85 1141 STUCKY@SU-CSLI.ARPA D-Lion Users
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 26 Aug 85 11:41:42 PDT
Date: Mon 26 Aug 85 11:35:02-PDT
From: Susan Stucky <Stucky@SU-CSLI.ARPA>
Subject: D-Lion Users
To: folks@SU-CSLI.ARPA, ckiparsky@XEROX.ARPA
Dear All,
This is a reminder of the D-Lion Users meeting tomorrow (that's Tuesday,
the 27th) at 1:30 in the Dandelion room in the trailers at Ventura. A
number of people have volunteered to talk about (and demonstrate, when
useful) some of the software, both the standard stuff and programs users
have developed. Hans, for instance, has offered to demonstrate
TEDITKEYPLUS. If you have anything you think is useful and that you
would be willing to demonstrate, please send me a message about it; the
information will make it easier to plan the meeting. Thanks.
-Susan
-------
∂26-Aug-85 1434 ullman@diablo surprise visit
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 26 Aug 85 14:34:31 PDT
Date: Mon, 26 Aug 85 14:28:20 pdt
From: Jeff Ullman <ullman@diablo>
Subject: surprise visit
To: nail@diablo
Tomasz Imielinski just told me he missed his plane and
wants to kill some time by coming over here.
He has done some work in an area that sounds similar to
what Jeff Naughton is doing: when are recursions "real"
and when are they replaceable by finite interations.
Anyone interested may meet in my office about 4:30 today
(Monday).
By the way, let's meet at 11AM for the regular nail meeting.
I'd like to focus on some open questions in rule evaluation.
---Jeff
∂30-Aug-85 1301 PATASHNIK@SU-SUSHI.ARPA [karp%ucbernie@Berkeley (Richard Karp):]
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 13:01:18 PDT
Date: Wed 28 Aug 85 13:22:42-PDT
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: [karp%ucbernie@Berkeley (Richard Karp):]
To: aflb.local@SU-SUSHI.ARPA
Date: Wed, 28 Aug 85 10:01:58 PDT
From: karp%ucbernie@Berkeley (Richard Karp)
Message-Id: <8508281701.AA03682@ucbernie.ARPA>
To: ashok@SU-SUSHI.ARPA, theory%ernie@Berkeley
SEMINAR ANNOUNCEMENT
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley 642-0143
Thursday, August 29 2 p.m. MSRI Lecture Hall
Zvi Galil Columbia University and Tel-Aviv University
Recent Results on the Complexity of the Minimum Spanning Tree Problem
Thursday, August 29 4 p.m. MSRI Lecture Hall
Structure in Complexity Theory Seminar
Juris Hartmanis MSRI
U:NP - Problems With Unique Solutions
-------
∂30-Aug-85 1324 ullman@diablo meeting today
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 12:55:19 PDT
Date: Wed, 28 Aug 85 09:49:24 pdt
From: Jeff Ullman <ullman@diablo>
Subject: meeting today
To: nail@diablo
We'll meet at 11AM in 301. I have no real agenda.
What I hope is that people will contribute their thoughts
on open questions. I have a few, but not enough to fill up
an hour.
---Jeff
∂30-Aug-85 1327 chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--September 3rd
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 13:27:46 PDT
Received: from ucbcogsci.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA00676; Thu, 29 Aug 85 14:09:44 pdt
Received: by ucbcogsci.ARPA (5.5/4.48)
id AA27201; Thu, 29 Aug 85 14:12:49 PDT
Date: Thu, 29 Aug 85 14:12:49 PDT
From: chertok%ucbcogsci@Berkeley (Paula Chertok)
Message-Id: <8508292112.AA27201@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley
Subject: UCB Cognitive Science Seminar--September 3rd
Cc: chertok%ucbcogsci@Berkeley
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, September 3, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:00 in 200 Building T-4
SPEAKER: Leonard Talmy, UCB
TITLE: ``Force Dynamics in Language and Thought''
A semantic category that has previously been neglected in
linguistic research is that of ``force dynamics''--how enti-
ties interact with respect to force. Included here is the
exertion of force, resistance to such a force, the overcoming
of such a resistance, blockage of the expression of force,
removal of such blockage, and the like.
Though scarcely recognized before, force dynamics figures
significantly in language structure. It is, first of all, a
generalization over the traditional notion of ``causative'':
it places naturally within a single framework not only `caus-
ing', but also `letting,' as well as a set of notions not nor-
mally considered in the same context.
Force dynamics, furthermore, plays a structuring role
across a range of language levels. First, it has direct gram-
matical representation. In English, such representation
appears not only in subsets of conjunctions, prepositions, and
other closed-class elements but, most significantly, also as
the semantic category that the modal system as a whole is
dedicated to expressing. Force dynamic patterns are also
incorporated in open-class lexical items, and bring numbers of
these together into systematic relationships. Lexical items
involved in this way refer not only to physical force interac-
tions but, by metaphoric extension, also to psychological and
social interactions, conceived in terms of psycho-social
``pressures.'' In addition, force dynamic principles can be
seen to operate in discourse that is involved with persuasion.
Such rhetorical interchange (including efforts to exhort, con-
vince, or logically demonstrate) involves the deployment of
points to argue for and against conflicting positions.
Force dynamics is a major conceptual organizing system,
constituting one of four major ``imaging'' systems that I have
developed which provide an integrated semantic schematization
of a referent scene. Cognitively, it corresponds to concepts
within ``naive physics'' as well as to ones in ``naive
(social) psychology,'' and can be contrasted with modern
scientific concepts in these domains.
--------------------------------------------------------------------
UPCOMING TALKS
Sept 10: Amos Tversky, Psychology, Stanford
Sept 17: Alan Schoenfeld, Education, UCB
Sept 24: Peter Pirolli, Education, UCB
Oct 1: David Rumelhart, UCSD
Oct 8: Terry Winograd, Computer Science, Stanford
Oct 15: Ron Kaplan, Xerox PARC
∂30-Aug-85 1342 HANS@SU-CSLI.ARPA talk by Uwe Reyle
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 13:38:57 PDT
Date: Tue 27 Aug 85 23:45:40-PDT
From: Hans Uszkoreit <Hans@SU-CSLI.ARPA>
Subject: talk by Uwe Reyle
To: folks@SU-CSLI.ARPA
Uwe Reyle of the University of Stuttgart (Germany) will give a talk
on "Grammatical Functions, Discourse Referents, and Quantification"
on Wednesday, August 28, at 15:15pm. The talk is part of the activities
of the Working Group on Syntax and Semantics and will take place in
the Ventura Hall Seminar Room.
-------
∂30-Aug-85 1348 EMMA@SU-CSLI.ARPA parking stickers
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 13:47:47 PDT
Date: Thu 29 Aug 85 09:45:18-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: parking stickers
To: folks@SU-CSLI.ARPA
Tel: 497-3479
Parking stickers have to be renewed by September 15th. We are doing a
group order to save people some hassle. If you are interested, please
fill out the form and bring it to either Jamie Marks or Ingrid
Deiwicks before next Thursday (Sept. 5). Stickers should arrive in
the following week.
You are allowed to buy parking stickers, if you are affiliated with
the university (staff, faculty, visiting scholar, student...).
Please send all queries to Jamie@csli.
-------
∂30-Aug-85 1355 @SU-CSLI.ARPA:chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--September 3rd
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 13:52:07 PDT
Received: from UCB-VAX.ARPA by SU-CSLI.ARPA with TCP; Thu 29 Aug 85 14:13:39-PDT
Received: from ucbcogsci.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA00676; Thu, 29 Aug 85 14:09:44 pdt
Received: by ucbcogsci.ARPA (5.5/4.48)
id AA27201; Thu, 29 Aug 85 14:12:49 PDT
Date: Thu, 29 Aug 85 14:12:49 PDT
From: chertok%ucbcogsci@Berkeley (Paula Chertok)
Message-Id: <8508292112.AA27201@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley
Subject: UCB Cognitive Science Seminar--September 3rd
Cc: chertok%ucbcogsci@Berkeley
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, September 3, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:00 in 200 Building T-4
SPEAKER: Leonard Talmy, UCB
TITLE: ``Force Dynamics in Language and Thought''
A semantic category that has previously been neglected in
linguistic research is that of ``force dynamics''--how enti-
ties interact with respect to force. Included here is the
exertion of force, resistance to such a force, the overcoming
of such a resistance, blockage of the expression of force,
removal of such blockage, and the like.
Though scarcely recognized before, force dynamics figures
significantly in language structure. It is, first of all, a
generalization over the traditional notion of ``causative'':
it places naturally within a single framework not only `caus-
ing', but also `letting,' as well as a set of notions not nor-
mally considered in the same context.
Force dynamics, furthermore, plays a structuring role
across a range of language levels. First, it has direct gram-
matical representation. In English, such representation
appears not only in subsets of conjunctions, prepositions, and
other closed-class elements but, most significantly, also as
the semantic category that the modal system as a whole is
dedicated to expressing. Force dynamic patterns are also
incorporated in open-class lexical items, and bring numbers of
these together into systematic relationships. Lexical items
involved in this way refer not only to physical force interac-
tions but, by metaphoric extension, also to psychological and
social interactions, conceived in terms of psycho-social
``pressures.'' In addition, force dynamic principles can be
seen to operate in discourse that is involved with persuasion.
Such rhetorical interchange (including efforts to exhort, con-
vince, or logically demonstrate) involves the deployment of
points to argue for and against conflicting positions.
Force dynamics is a major conceptual organizing system,
constituting one of four major ``imaging'' systems that I have
developed which provide an integrated semantic schematization
of a referent scene. Cognitively, it corresponds to concepts
within ``naive physics'' as well as to ones in ``naive
(social) psychology,'' and can be contrasted with modern
scientific concepts in these domains.
--------------------------------------------------------------------
UPCOMING TALKS
Sept 10: Amos Tversky, Psychology, Stanford
Sept 17: Alan Schoenfeld, Education, UCB
Sept 24: Peter Pirolli, Education, UCB
Oct 1: David Rumelhart, UCSD
Oct 8: Terry Winograd, Computer Science, Stanford
Oct 15: Ron Kaplan, Xerox PARC
∂30-Aug-85 1407 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa moving
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 12:57:43 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Tue 27 Aug 85 21:45:03-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Tue 27 Aug 85 21:45:05-PDT
Received: by wisc-rsch.arpa; Tue, 27 Aug 85 23:32:06 cdt
Message-Id: <8508280423.AA16622@wisc-rsch.arpa>
Received: from csnet-relay.arpa by wisc-rsch.arpa; Tue, 27 Aug 85 23:23:29 cdt
Received: from ibm-sj by csnet-relay.csnet id ad17724; 28 Aug 85 0:18 EDT
Date: Tue, 27 Aug 85 20:50:35 PDT
From: Peter van Emde Boas <pveb%ibm-sj.csnet@csnet-relay.arpa>
To: udi@wisc-rsch.ARPA
Subject: moving
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
Dear friends
We are heading back east to Holland. After August 30 we will no longer be
reachable at IBM San Jose.
Our Home address, effective Sep 19 1985 will be restored to be
Peter, Ghica, Donald, Caspar and Evert van Emde Boas
Beethovenlaan 44
2102 EW Heemstede
Netherlands
Phone: 011-31-23-281598
Peter's work address:
IIW/FVI, Univ. of Amsterdam
Roetersstraat 15
1018 WB Amsterdam
Netherlands
Phone: 011-31-20-5223063 (secr) 5223065 (office)
Electronic address: mcvax!uva!peter@SEISMO
Ghica's Work address:
IBM INS/DS
PO box 24
1420 AA Uithoorn
Netherlands
Phone: 011-31-2975-53528
VNET address: EMDEBOAS AT UITVM1
Don't hesitate to continue sending electronic mail. I consider
it most helpful.
We enjoyed our stay in the US for the past eight months and all the
hospitality experienced. If you ever get to Holland please use the
above addresses and phone numbers for contacting us.
Greetings Peter.
∂30-Aug-85 1409 EMMA@SU-CSLI.ARPA Re: parking stickers
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 14:08:01 PDT
Date: Thu 29 Aug 85 14:23:49-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Re: parking stickers
To: folks@SU-CSLI.ARPA
In-Reply-To: Message from "Michael Georgeff <georgeff@SRI-AI.ARPA>" of Thu 29 Aug 85 13:56:05-PDT
Tel: 497-3479
Forms were issued to all employees of Stanford University. If you
did not get a parking sticker form, you can pick one up at the
Stanford Police Station.
ps. CSLI is not able to get any extra blank forms for the people
at SRI or Xerox who might need a parking sticker.
pps. Please address queries to Jamie; any queries addressed to me will
be passed along to him, but you will probably have to wait longer for
an answer.
-------
∂30-Aug-85 1427 EMMA@SU-CSLI.ARPA Newsletter August 29, No. 43
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 13:45:17 PDT
Date: Wed 28 Aug 85 17:10:02-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter August 29, No. 43
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
August 29, 1985 Stanford Vol. 2, No. 43
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, August 29, 1985
12 noon TINLunch
Ventura Hall ``A Unified Indexical Analysis of ``same'' and
Conference Room ``different'': A Response to Stump and Carlson''
by David Dowty
Discussion led by Mats Rooth
2:15 p.m. CSLI Talk
Ventura Hall No talk this week
Conference Room
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, September 5, 1985
12 noon TINLunch
Ventura Hall ``Predication, Logical Syntax, and the Type-free
Conference Room Conception of Properties, Relations, and Propositions''
Discussion led by Chris Menzel
(Abstract on page 2)
2:15 p.m. CSLI Talk
Ventura Hall No talk this week
Conference Room
3:30 p.m. Tea
Ventura Hall
!
Page 2 CSLI Newsletter August 29, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S TINLUNCH
``Predication, Logical Syntax, and the Type-free Conception
of Properties, Relations, and Propositions''
Since Frege, the (arguably) dominant conception of properties,
relations, and propositions (PRPs) has been typed. The first rigorous
formal development of this view by Russell was motivated largely by
his discovery of the justly famous paradox that bears his name, and
was for many years considered the definitive solution to the problem.
More recently, the view (albeit in extensionalist garb) has enjoyed a
renewed respectability, and a renewed applicability, in linguistics
and the philosophy of language prompted by Montague's assiduous
investigations into the semantics of natural language.
Recent years, however, have seen a growing dissatisfaction with the
typed conception of PRPs. I will begin this week's discussion by
pointing out some of the problems lurking behind this dissatisfaction,
and will then present the basics of a type-free alternative. Despite
the fact that Frege himself had a typed conception of PRPs, the
type-free view I will present is largely Fregean in spirit: I will
argue in particular that properties and relations are in some sense
``unsaturated.'' This insight, however, doesn't require typing, as
Frege seemed to think, and I will show where, in my view, he went
wrong. I will then argue that the standard function/argument notation
of first- and higher-order logic ought, as Frege intended, to be
thought of as representing the ``completion'' of an unsaturated
property or relation, and not, contra Bealer, the standing of two or
more objects in a further relation of predication. This suggests a
number of important questions about the nature of logic that will be
raised for discussion. --Chris Menzel
←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
``Swedish Ditransitives''
Summary of the meeting on Thursday, August 22
In most Swedish ditransitive sentences, either object may
passivize. This talk addressed the question of what special property
of Swedish permits the second object to advance to subjecthood in the
passive. It was argued that the property in question is a disjunction
between two syntactic functions, SUBJECT and TOPIC, on the
sentence-initial position (the verb-second constraint). Subjects can
be distinguished from topics through various syntactic tests (e.g.,
embedding under raising verbs), but this distinction is often opaque
in simple clauses. It was argued that this conflation of two
alternative functions on a single constituent structure node has
caused the topic to be reanalyzed as a subject. Since topicalization
does not alter grammatical relations, it applies freely to second
objects in Swedish and English. But only in Swedish can this
topicalized second object be reanalyzed as a subject. When the source
(before topicalization) is an impersonal passive construction, the
result is a passivized second object.
Finally, a ``movement'' analysis, in which topicalization and
passivization are two instances of a single process defined on
c-structure (such as ``move alpha''), was rejected. With verbs
subcategorized for both a direct object and an oblique function, the
prepositional object topicalizes but does not passivize, even in
identical c-structures. This suggests that the two processes belong
to different sub-components of the syntax. --Steve Wechsler
!
Page 3 CSLI Newsletter August 29, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
NEW CSLI REPORTS
Report No. CSLI-85-29, ``Equations, Schemata and Situations: A
framework for linguistic semantics'' by Jens Erik Fenstad,
Per-Kristian Halvorsen, Tore Langholm, and Johan van Benthem, and
Report No. CSLI-85-30, ``Institutions: Abstract Model Theory for
Computer Science'' by J. A. Goguen and R. M. Burstall, have just been
published. These reports may be obtained by writing to David Brown,
CSLI, Ventura Hall, Stanford, CA 94305 or Brown@SU-CSLI.
-------
∂30-Aug-85 1626 NEUMANN@SRI-CSLA.ARPA RISKS-1.3, 30 Aug 85
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 16:25:56 PDT
Return-Path: <Neumann@SRI-CSL.ARPA>
Received: from SRI-CSL.ARPA by SRI-CSLA.ARPA with TCP; Fri 30 Aug 85 12:40:09-PDT
Received: from SRI-CSLB by SRI-CSL via DDN; 30 Aug 85 12:35:20-PDT
Date: Fri 30 Aug 85 12:35:09-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: RISKS-1.3, 30 Aug 85
To: RISKS: ;
ReSent-Date: Fri 30 Aug 85 16:25:13-PDT
ReSent-From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
ReSent-To: jmc-lists@SU-AI.ARPA
RISKS-FORUM Digest Friday, 30 Aug 1985 Volume 1 : Issue 3
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
(Contributions to RISKS@SRI-CSL.ARPA)
(Requests to RISKS-Request@SRI-CSL.ARPA)
(This vol/no can be FTPed from SRI-CSL:<RISKS>RISKS-1.3)
(Issue n of vol 1 is in SRI-CSL:<RISKS>RISKS-1.n)
Contents:
Miscellaneous comments on V1#2 (Dave Curry)
Computer/hardship list (Jerome Rosenberg)
Medical KBES -- Some AI systems may need FDA approval
Health hazards of CRT use (Robin Cooper)
----------------------------------------------------------------------
Date: Thu, 29 Aug 85 21:22:44 EST
From: davy@purdue-ecn.ARPA (Dave Curry)
To: risks@sri-csl.arpa
Subject: Miscellaneous comments on V1#2
Just some miscellaneous comments on some of the things in RISKS V1#2.
Hope this isn't too long.
1) Fishermen. This sounds like a crock to me. I wonder whether the
broken buoy or the fact that the storm was not predicted was the deciding
factor in the case. Since the NWS/NOAA is providing a service, which
nobody is *required* to use, I can't understand how they can be sued for
not predicting a storm. What would happen if they predicted a storm which
never showed up? Could all the fishermen who stayed home sue for their
lost profits? I can see it now.... "Cloudy Thursday, rain Friday -- use
this information at your own risk."
2) Union Carbide. I always wonder in cases like this whether the plant is
actually having more accidents than usual, or if because of Bhopal we're
just hearing about it more because the press has a new victim to pick on.
The number of accidents at that plant is disgraceful. Does anyone think
the government will shut it down?
3) Bob Carter's comments. I think I agree with PGN on these... I would
prefer to see RISKS cover more or less anything related to computer
"hazards", rather than centering on one or two things. There are plenty
of other lists which already take certain parts of this (e.g. SOFT-ENG for
"who's responsible" type stuff, ARMS-D for SDI). I also like the SEN
quotes -- I don't personally read SEN, and even if some of the stuff is
dumb (computer kills scientist), overall I think the brief summary PGN
provided in V1 #1 gives a nice broad range of topics to discuss.
4) Medical programs. I'm not sure I trust these fully yet. I'd have no
qualms about my doctor using one to *suggest* things to him, but I would
draw the line at his accepting the program's diagnosis unless he could
verify on his own that it was correct. For example, a heart specialist
interpreting a heart-diagnosis program's output would be good; a general
practicioner's taking it as gospel would not be good. We need to make sure
the doctor is capable of knowing when the program is wrong. (I saw a
comment about MYCIN once - "if you brought MYCIN a bicycle with a flat
tire, it would try like hell to find you an antibiotic.")
5) SDI. I'm going to leave this for the experts. I personally lean
towards Parnas's "side", but I don't know enough about it. I do
like reading the comments on it though. (BTW, for those of you who
haven't yet read Herb Lin's paper, it's excellent.)
Great list so far... keep it coming. As a (possibly) new topic, did
anyone go to this AI show in San Diego (?) or wherever? I saw a blurb on
it somewhere... how about a review of what the current toys are and what
risks they may take? I remember seeing something about a program to
interpret the dials and gauges of a nuclear power plant....
--Dave Curry
davy@purdue-ecn
------------------------------
Date: Thu, 29 Aug 85 14:00:58 cdt
From: jerome@wisc-rsch.arpa (Rosenberg Jerome)
To: risks@sri-csla
Subject: Computer/hardship list
Peter: One basis for a focussed discussion of risks would be to try to
establish a list of those computer systems whose failure would cause great
hardship --economic, political, social --to a significant number of our
citizens. For example, the failure of our computer-controlled electric
power grid or the failure of the Reserve's check clearance system.
Your readers/participants could be asked to suggest the systems
to be included on the list. Your forum could then discuss probabilies
of failure,costs of failures vs failure time, etc. etc..
Jerry
------------------------------
Date: Friday, 30 Aug 1985 05:37:48-PDT
From: goun%cadlac.DEC@decwrl.ARPA (Ave decus virginum!)
To: risks@SRI-CSL.ARPA
Subject: Medical KBES
Some AI systems may need FDA approval
Expert systems come within the FDA ambit to the extent that
they supplement doctor's work, according to Richard Beutal, a
Washington D.C. attorney specializing in the legal aspects of
technology.
An expert system may be defined as a computer program that
embodies the expertise of one or more human experts in some
domain and applies this knowledge to provide inferences and
guidance to a user. some of the earliest and most
sophisticated systems were developed for medical diagnosis:
MCYIN, EMCYIN, CADUCEUS AND ATTENDING. [There are several
more in use in Japan. --mjt]
Beutal called attention to proposed FDA regulations that, if
implemented, would require medical expert systems to obtain
FDA pre-marketing approval. Given that FDA approval for what
are class 3 devices could take up to 10 years and that
reclassifying such devices can take almost as long, these FDA
regulations would virtually cause investment to dry up.
{Government Computer News Aug 16, 1985}
------------------------------
Date: Thu, 29 Aug 85 10:35:20 cdt
From: cooper@wisc-ai.arpa (Robin Cooper)
To: risks@sri-csl
Subject: health hazards of CRT use
With respect to the introduction of the topic of the health hazards of
using video terminals, I would be particularly interested in seeing
discussion of risks to pregnant women and their unborn children. Both
Sweden and Canada have apparently introduced legislation which gives
pregnant women the right to change job assignments, whereas the
official US line seems to be that there is not sufficient risk to
warrant this.
Robin Cooper
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂01-Sep-85 2356 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa IJPP: new journal on parallel programming
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 23:56:43 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Sun 1 Sep 85 23:52:18-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Sun 1 Sep 85 23:52:21-PDT
Received: by wisc-rsch.arpa; Mon, 2 Sep 85 01:35:54 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Mon, 2 Sep 85 01:29:27 cdt
Message-Id: <8509020629.AA23525@wisc-crys.arpa>
Date: Sun 1 Sep 85 23:29:07-PDT
From: Gary Lindstrom <Lindstrom@UTAH-20.ARPA>
Subject: IJPP: new journal on parallel programming
To: potential-authors:;
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
The following is an announcement of a new journal. Contributions are now
actively being solicited, as explained below. Please post this message
on local bulletin boards (hard and soft!).
Thanks,
--Gary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
INTERNATIONAL JOURNAL OF PARALLEL PROGRAMMING
Editor-in-Chief:
Gary Lindstrom
Department of Computer Science
University of Utah
Salt Lake City, Utah 84112
(801) 581-5586
Lindstrom@Utah-20.ARPA
Published by:
Plenum Publishing Corporation
233 Spring Street
New York, NY 10013
(212) 620-8000
Statement of Purpose:
Parallel computer systems are characterized by the coexistence of
multiple coordinated activities. Physically, such systems range from networked
independent computers to high performance single-chip processors.
While parallelism has long been a physical reality in computer systems,
its impact on programming practice has in the past generally been felt only by
specialists in systems programming. A new trend, however, is clearly emerging:
that of parallelism as a vital aspect of programming at all levels.
The reasons for this trend are several, including the growing purview
of higher level languages, more elegant computing models relieved of sequential
computing ideology, and exciting new ideas in computer architecture motivated
by the advent of VLSI.
The International Journal of Parallel Programming (IJPP) will offer a
window on these developments from a programmer's perspective. Thus while no
pertinent aspect of parallel computing systems will be excluded a priori,
each contribution will observe the common theme of illuminating in some manner
the programming challenges presented by parallel computing systems.
Scope:
Sample areas to be addressed in IJPP include (with a short suggestive
list of appropriate subareas mentioned in each case):
* linguistic foundations (semantic formulations, abstract machine
models)
* conceptual frameworks for parallel computation (actors, guardians,
synchronized tasks, functional and logic programming)
* high-level languages for parallel programming (new formulations and
extensions to existing languages)
* evaluation methods (dataflow, reduction, eager vs. lazy evaluation)
* implementation techniques (compilation, emulation, storage and
name space management)
* programming support systems (run-time libraries, debuggers,
performance instruments)
* pragmatic considerations (task granularity, load distribution and
scheduling, error detection and recovery)
* architectural characteristics (synchronous vs. asynchronous control,
shared vs. partitioned memory, physical locality, reliability)
* software engineering aspects (specification and design
methodologies, rapid prototyping, migration of sequential code,
verification and testing)
* advances in parallel algorithms (prototypical problems, relationships
to particular languages and evaluation methods)
* performance studies (fundamental and empirical)
* application studies (artificial intelligence, simulation, databases,
numeric computation)
In addition to full length refereed contributions, IJPP will offer a
department entitled "Nonpareil" (meaning, in French, both "nonparallel" and
"matchless"). Under this rubric will appear short contributions of a lighter
nature, including anecdotes, tongue-in-cheek commentary, and other entertaining
insights into the travails of parallel programming.
Editorial Board:
A distinguished Editorial Board comprising approximately 20 experts in
the areas cited above is now being formed.
Commencement of the Journal:
The first issue of IJPP will appear on or about July 1, 1986. Six
issues of approximately 90 pp. each will be issued per year.
IJPP will be the successor to the International Journal of Computer and
Information Sciences, concluding fourteen volumes published under the
editorship of Julius T. Tou. The first issue of IJPP will thus be designated
volume 15, number 1.
Call for Papers:
Manuscripts for possible publication in IJPP should be sent to the
Editor-in-Chief. Contributions must be in English, and previously unpublished.
Four single-sided copies are requested.
To ensure eligibility for inclusion in the inaugural issue, manuscripts
should be received by October 15, 1985.
Electronic mail will be used for correspondence with contributors
whenever feasible, and network addresses should be prominently indicated on
all submissions and inquiries.
-------
-------
∂02-Sep-85 1406 @SU-SUSHI.ARPA:PAPA@SU-SCORE.ARPA Ride for Berkeley
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 14:06:17 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Mon 2 Sep 85 14:01:59-PDT
Date: Mon 2 Sep 85 14:02:06-PDT
From: C. Papadimitriou <PAPA@SU-SCORE.ARPA>
Subject: Ride for Berkeley
To: aflb.local@SU-SCORE.ARPA
Message-ID: <12140118399.23.PAPA@SU-SCORE.ARPA>
Is anybody driving to Berkeley Tuesday before noon for the talks?
If so, I need a ride.
---Christos.
-------
∂02-Sep-85 2235 NEUMANN@SRI-CSLA.ARPA RISKS-1.4, 02 Sep 85
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 22:35:39 PDT
Date: Mon 2 Sep 85 21:57:22-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: RISKS-1.4, 02 Sep 85
To: RISKS: ;
RISKS-FORUM Digest Monday, 2 Sept 1985 Volume 1 : Issue 4
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
(Contributions to RISKS@SRI-CSL.ARPA)
(Requests to RISKS-Request@SRI-CSL.ARPA)
(Issue n of vol 1 is in SRI-CSL:<RISKS>RISKS-1.n)
Contents:
The Case of the Broken Buoy (Matt Bishop)
Inaction; Buoys will be buoys; KAL 007; Malpractice (PGN)
Health Hazards of CRT Use (Brint Cooper, Robin Cooper, PGN)
Medical Software (Brint Cooper)
Rolm's Hawk-32 (Doug Bryan)
----------------------------------------------------------------------
Date: 30 Aug 1985 1636-PDT (Friday)
From: Matt Bishop <mab@riacs.ARPA>
Organization: Research Institute for Advanced Computer Science
Address: Mail Stop 230-5, NASA Ames Research Center, Moffett Field, CA 94035
Phone: (415) 694-6363 [main office], (415) 694-6921 [my office]
Mythological-Animal: Unicorn
Pet-Peeve: Complaints about the number of header fields
Snack-Food: White-shelled Pistachio Nuts
To: risks@sri-csl.ARPA
Subject: The Case of the Broken Buoy
Dave Curry's right. I remember reading a newspaper report which
said, in essence, that the NWS/NOAA lost because it had failed to
predict the storm. I didn't believe it, so I read on, and the report
said that since they had known of a broken buoy, had failed to repair
it (I think it had been broken for several months), and therefore failed
to get the information needed to give a warning, they were guilty of
negligence and had to pay. Quite a far cry from what the story had
begun as!
------------------------------
Date: Mon 2 Sep 85 14:05:15-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Inaction; Buoys will be buoys; KAL 007; Malpractice
To: RISKS@SRI-CSLA.ARPA
The issue of the lobstermen indeed rested on the negligence of not repairing
the buoy. (As noted in RISKS-1.2, the weather buoy went unrepaired for
three months.)
Negligence and inaction in the presence of informed knowledge are likely to
be the source of more lawsuits in the future. For example, the NY Times of
1 September 85 had an article by Richard Witkin on KAL 007.
Evidence introduced in lawsuits filed in connection with the Soviet downing
of the Korean Air Lines Flight 007 suggests that American radar operators
knew hours beforehand that the jetliner was off course and heading into
Soviet airspace.
The words, "We should warn him", presumably referring to the plane's pilot,
were heard at the Government's civil air-traffic control station in Alaska
as the Boeing 747 strayed off course toward its fatal encounter with a
Soviet fighter plane two years ago today, according to the documents.
The documents were submitted Friday as evidence in damage suits filed
against the United States Government by relatives of the 269 people who
died in the incident.
Medical malpractice suits have been on the upswing, and doctors are taking
extraordinary measures to compensate -- such as higher prices and otherwise
unnecessary tests and drugs. But the question of what constitutes
computer-related malpractice is likely to emerge as a very sticky one, e.g.,
faulty computer system design, life-critical application programming, and
sloppy computer operation. And what about a debugger or maintainer who
notices something fishy but does not carry through? A remarkable case of a
casual observer playing a significant role took place on 1 Sept 85 when a
passenger on People Express Flight 183 from Dulles to Newark noticed minutes
after take-off that a cowling was missing on one of the engines. (The plane
returned to Dulles.) Imagine a lawsuit against a company, which in turn
sues the programmer. The potential for legal confusion relating to computer
systems is really quite awesome, and the confusion has just begun. Suppose
the windshear-warning system is finally installed (with the 31 May 84
near-disaster on take-off of a UA 727 and the recent crash providing an
impetus), and suppose that program has a bug? Suppose the computer is not
working on landing? There are some very serious questions that must be
raised. The incidence of high-award law suits elsewhere is likely to
provide a strong forcing function.
------------------------------
Date: Fri, 30 Aug 85 21:56:09 EDT
From: Brint Cooper <abc@BRL.ARPA>
To: cooper@WISC-AI.ARPA
cc: risks@sri-csl.ARPA
Subject: Re: health hazards of CRT use
To balance this discussion, we need to include risks to pregnant women
and their born and unborn children of television sets that run 18 hours
a day in the home.
Keep in mind: X-radiation is generally produced by the very high
voltages traditionally used in color television sets and composite-video
color monitors. Many of the monochrome monitors need no such voltages
and, so, produce no such radiation.
Since most folks are now buying color TVs for their homes, we need to
examine that aspect of safety as well, especially since many of them are
used as monitors for home computers and video games.
Brint Cooper
------------------------------
Date: Sun, 1 Sep 85 12:13:49 cdt
From: cooper@wisc-ai.arpa (Robin Cooper)
To: abc@BRL.ARPA
Cc: risks@sri-csl.ARPA
Subject: Re: health hazards of CRT use
Yes, that seems right, though I wonder what the facts are concerning
how close one sits to the device. People spend more time a few feet
away from their terminals than their TVs.
Robin Cooper
------------------------------
Date: Mon 2 Sep 85 21:10:33-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Re: health hazards of CRT use
To: RISKS@SRI-CSLA.ARPA
There is also discussion in the literature on physical and psychological
problems resulting from sitting in front of your terminal for hours, most
notably back and neck problems, tension, stress, anxiety, and subsequent
depression. This forum is not really the place to discuss another relevant
aspect of the problem, but let me just mention it anyway and then discourage
further commentary on it: the standard American junk-food diet of coffee,
colas, and caffeine generally, orange juice, sugar, chocolate (containing
both sugar and caffeine), refined white flour, fried foods, and so on, is
now being linked with making many of those problems worse.
------------------------------
Date: Fri, 30 Aug 85 22:00:55 EDT
From: Brint Cooper <abc@BRL.ARPA>
To: davy@EE.ARPA
cc: risks@SRI-CSL.ARPA
Subject: Medical Software
Actually, culpability for mistakes caused by medical diagnosis software
could be placed with the same person who is responsible for correct
interpretation of all diagnosis aids: the physician him/herself.
Programmers, like authors of medical texts, are providing tools for the
physician, not replacing him or her.
What we CAN do as computer scientists, et al., is to educate the
medical profession to the limitations of these tools as well as to their
benefits. For ourselves, the goals should include error and risk
reduction as we continue to discuss.
Brint
------------------------------
Date: Sat 31 Aug 85 22:58:00-PDT
From: Doug Bryan <BRYAN@SU-SIERRA.ARPA>
Subject: Rolm's Hawk-32
To: risks@SRI-CSL.ARPA
Speaking of possible hazards due to hardware failure, has anyone out there
had any experience with Rolm's 32 bit Mil Spec machine the Hawk-32? Since
the Hawk is a Mil Spec machine, I'm sure it will be used in situations where
failure could lead loss of life.
I would be interested in hearing about the Hawk's environment limitations,
mean time between failures and any other experiences people have had with
the machine.
doug
[POSTSCRIPT: A few of you complained that the first issue had too much
of a military flavor. It is interesting that except for this last
item, this issue and the previous issue had almost none! On the
other hand, the problems we are dealing with are universal, and
we should be able to learn from all relevant discussions...
I had some complaints about the format breaking your dedigestifying
programs. I hope this is better, but if it really is, your programs
must be pretty stupid. I did not change anything except the trailer.
So maybe I don't have it right yet?
Others complained that the issues were too big and did not come out
often enough. (I explained why -- I wasn't around.) Now you will
undoubtably complain that that they are too small and too frequent.
But it really depends on what contributions are available. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂03-Sep-85 1004 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa call for papers - MIT conference on VLSI
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 10:03:49 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Tue 3 Sep 85 10:01:32-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Tue 3 Sep 85 10:01:36-PDT
Received: by wisc-rsch.arpa; Tue, 3 Sep 85 11:37:33 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Tue, 3 Sep 85 11:06:22 cdt
Received: from MIT-MC.ARPA by wisc-crys.arpa; Tue, 3 Sep 85 11:06:15 cdt
Date: Tue, 3 Sep 85 12:04:51 EDT
From: E.Leiserson@wisc-rsch.arpa
To: theory@WISC-CRYS.ARPA
Subject: call for papers - MIT conference on VLSI
Message-Id: <[MIT-MC.ARPA].631653.850903.CEL>
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
CALL FOR PAPERS
Fourth MIT Conference on
ADVANCED RESEARCH IN VLSI
April 7-9, 1986
Massachusetts Institute of Technology
Cambridge, Massachusetts
The field of VLSI (Very Large Scale Integration) is an interrelated
set of technical disciplines including semiconductor devices,
processes, and patterning, and also circuit design, design automation,
systems architecture, and complexity theory. Successful advanced
research in any of these areas requires understanding of the other
areas--system architects and designers must understand the limitations
imposed by the physical and chemical processes, and conversely,
advances in device design occur best when circuit and architectural
requirements are known. This conference seeks to promote interaction
among reseach workers in all disciplines that relate to integrated
circuits.
Call for Contributed Papers
Original research papers may be submitted in any of the following
areas:
- Innovative Electrical Circuits - Artificial Intelligence Applications
- Process and Device Modeling - Layout and Routing
- Hardware Design Languages - Silicon Compilation
- VLSI Systems - Testing and Fault Tolerance
- Special-Purpose Architectures - Highly Parallel Architectures
- Analysis and Simulation - Highly Parallel Problem Domains
- Sensory Systems - VLSI Theory
DRAFT PAPERS (twelve copies) should be sent before October 1, 1985 to
Charles E. Leiserson, Program Chairman, at the Conference mailing
address:
Charles E. Leiserson, Program Chairman
Room 39-321
Massachusetts Institute of Technology
Cambridge, MA 02139
Drafts should be sufficiently detailed to permit a review by the
program committee. Notification of acceptances will be sent to
authors by November 1, 1985. Camera-ready copy of papers for the
Proceedings is due January 1, 1986.
Invited Speakers
The invited speakers are leaders in the theory and practice of
parallel computation. They include:
Kenneth E. Batcher (Goodyear) MPP
Randall Rettberg (BBN) Butterfly
Danny Hillis (TMC) Connection Machine
Jack Dennis (MIT) Dataflow
Charles L. Seitz (Caltech) Mosaic
Leslie G. Valiant (Harvard) Interconnection Networks
Allan Gottlieb (NYU) Ultracomputer
Richard M. Karp (Berkeley) Parallel Complexity
David Elliot Shaw (Columbia) NON-VON
Attendance Information
Arrangements for the Conference will be similar to those for the MIT
conferences held in 1980, 1982, and 1984. The conference will be
relatively small and informal. Attendance is by invitation only. For
Information, write to Paul Church, Registrations, Room 39-321, MIT,
Cambridge, MA 02139, or telephone (617) 253-8138.
Organization of the Conference
The conference is organized by the Microsystems Program
Office, MIT. The program committee consists of H. Fuchs (UNC),
Kim Kokkonen, (Intel), H. T. Kung (CMU), F. T. Leighton (MIT),
C. E. Leiserson, Chairman (MIT), R. J. Lipton (Princeton),
R. F. Lyon (Schlumberger), F. P. Preparata (Illinois),
C. D. Thompson (Berkeley), J. D. Ullman (Stanford),
and R.E. Zippel (MIT).
The MIT local committee consists of J. Allen, D. Antoniadis,
L. Glasser, T. Knight, H. Lee, B. Lory, P. Penfield, Chairman,
J. Raffel, H. Smith, C. Sodini, C. Terman and J. Wyatt.
-------
∂03-Sep-85 1530 ullman@diablo paper received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 15:30:05 PDT
Date: Tue, 3 Sep 85 15:12:56 pdt
From: Jeff Ullman <ullman@diablo>
Subject: paper received
To: nail@diablo
I have a copy of "Query Optimization in Logical Databases"
by Kifer and Lozinskii.
They talk about how to push selections and projections through
Horn clauses.
Anybody want to see it?
PS: When I offer to distribute papers like this, I'm really
talking to local Stanford people.
I know that people outside Stanford get NAIL mail, which is
fine with me. But please treat messages like this as an
announcement that the paper exists, and contact the author,
not me, for a copy. Thanks.
---Jeff
∂03-Sep-85 1654 RICE@SUMEX-AIM.ARPA Wednesday's Meeting
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 16:54:07 PDT
Date: Tue 3 Sep 85 16:54:12-PDT
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: Wednesday's Meeting
To: aap@SUMEX-AIM.ARPA
Message-ID: <12140411872.66.RICE@SUMEX-AIM.ARPA>
Sorry about the late message everyone.
I haven't been able to organise anything for tomorrow so unless anyone
else can get something together I hereby declare tomorrow's meeting
to be null and void.
On a brighter note there WILL be a meeting next week. This will be
as follows :-
Wed Sept 11
9 A.M. (ghasp)
Dr. Shimon Cohen
from Schlumberger P.A. res. will describe language development
work that he is doing as part of the Faim project.
(many thanks to our leader for lining this one up)
Rice
-------
∂03-Sep-85 1815 BRAD@SU-CSLI.ARPA vacation
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 18:15:14 PDT
Date: Tue 3 Sep 85 18:06:01-PDT
From: Brad Horak <BRAD@SU-CSLI.ARPA>
Subject: vacation
To: folks@SU-CSLI.ARPA
I'll be on vacation from September 4th until September 16th. Please be aware
that I won't be able to answer any net mail until I return. I would
appreciate a cc of any message concerning problems that would normally be
sent to me - it beats coming home to an empty mailbox!
--Brad
-------
∂04-Sep-85 1038 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 10:38:21 PDT
Received: from ames-vmsb.ARPA by SU-SCORE.ARPA with TCP; Wed 4 Sep 85 10:33:32-PDT
Date: 4 Sep 85 09:49:00 PDT
From: welch@ames-vmsb.ARPA
Subject: SIGBIG
To: super@su-score.arpa
Reply-To: welch@ames-vmsb.ARPA
ASSOCIATION FOR COMPUTING MACHINERY
San Francisco Golden Gate Chapter
"SIGBIG" Special Interest Committee
For Large High Speed Computers
Meetings on the first Wednesday of each month at 7:30 PM. Speakers
who can give insights to various aspects of SUPERCOMPUTING are
featured each month.
Next meeting:
Wednesday, September 4,1985, 7:30 PM
Speaker: Doug Vaughan/Alliant
The Atrium building
5776 Stoneridge Mall Road
Pleasanton
Directions: Take the Foothill offramp South from Hwy 580
(Half a mile West from the intersection of
580 and 680 in Pleasanton)
Turn left at the second light onto DEODAR
Turn right at the first stop sign onto Stoneridge Mall Rd
second building on your right is the Atrium.
The conference room is on the bottom floor next to
Bagels and Lox deli
---------------------------------------------------------------
Tape-recordings of most of the previous may be obtained
in exchange for a tape cassette or $5.00 by contacting:
Mary Fowler (415)261-4058
Supercomputing #192, BOX 2787
Alameda, CA. 94501-0787
For information contact Mary Fowler, Chairperson (415) 261-4058
or Mike Austin, Publ. Chair (415) 423-8446
------
∂04-Sep-85 1346 chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--Sept 10
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 13:46:41 PDT
Received: from ucbcogsci.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA00494; Wed, 4 Sep 85 13:40:04 pdt
Received: by ucbcogsci.ARPA (5.5/4.48)
id AA11537; Wed, 4 Sep 85 13:43:19 PDT
Date: Wed, 4 Sep 85 13:43:19 PDT
From: chertok%ucbcogsci@Berkeley (Paula Chertok)
Message-Id: <8509042043.AA11537@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley
Subject: UCB Cognitive Science Seminar--Sept 10
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, September 10, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Amos Tversky, Department of Psychology,
Stanford University
TITLE: ``Misconception of Chance Processes in
Basketball''
We investigate the origin and the validity of common beliefs
regarding ``the hot hand'' and ``streak shooting'' in the game
of basketball. Basketball players and fans alike tend to
believe that a player's chance of hitting a shot are greater
following a hit than following a miss on the previous shot.
However, detailed analyses of the shooting records of the Phi-
ladelphia 76ers provided no evidence for a positive correla-
tion between the outcomes of successive shots. The same con-
clusions emerged from free-throw records of the Boston Cel-
tics, and from a controlled shooting experiment with the men
and women of Cornell's varsity teams. The outcomes of previ-
ous shots influenced Cornell players' predictions but not
their preformance. The belief in the hot hand and the
``detection'' of streaks in random sequences is attributed to
a general misconception of chance according to which even
short random sequences are thought to be highly representative
of their generating process.
--------------------------------------------------------------
UPCOMING TALKS
Sept 17: Alan Schoenfeld, Education, UCB
Sept 24: Peter Pirolli, Education, UCB
Oct 1: David Rumelhart, Cognitive Science, UCSD
Oct 8: Terry Winograd, Computer Science, Stanford
Oct 15: Ron Kaplan, Xerox PARC
Oct 22: Lotfi Zadeh, Computer Science, UCB
∂04-Sep-85 1354 @SU-CSLI.ARPA:chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--Sept 10
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 13:53:39 PDT
Received: from UCB-VAX.ARPA by SU-CSLI.ARPA with TCP; Wed 4 Sep 85 13:44:11-PDT
Received: from ucbcogsci.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA00494; Wed, 4 Sep 85 13:40:04 pdt
Received: by ucbcogsci.ARPA (5.5/4.48)
id AA11537; Wed, 4 Sep 85 13:43:19 PDT
Date: Wed, 4 Sep 85 13:43:19 PDT
From: chertok%ucbcogsci@Berkeley (Paula Chertok)
Message-Id: <8509042043.AA11537@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley
Subject: UCB Cognitive Science Seminar--Sept 10
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, September 10, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Amos Tversky, Department of Psychology,
Stanford University
TITLE: ``Misconception of Chance Processes in
Basketball''
We investigate the origin and the validity of common beliefs
regarding ``the hot hand'' and ``streak shooting'' in the game
of basketball. Basketball players and fans alike tend to
believe that a player's chance of hitting a shot are greater
following a hit than following a miss on the previous shot.
However, detailed analyses of the shooting records of the Phi-
ladelphia 76ers provided no evidence for a positive correla-
tion between the outcomes of successive shots. The same con-
clusions emerged from free-throw records of the Boston Cel-
tics, and from a controlled shooting experiment with the men
and women of Cornell's varsity teams. The outcomes of previ-
ous shots influenced Cornell players' predictions but not
their preformance. The belief in the hot hand and the
``detection'' of streaks in random sequences is attributed to
a general misconception of chance according to which even
short random sequences are thought to be highly representative
of their generating process.
--------------------------------------------------------------
UPCOMING TALKS
Sept 17: Alan Schoenfeld, Education, UCB
Sept 24: Peter Pirolli, Education, UCB
Oct 1: David Rumelhart, Cognitive Science, UCSD
Oct 8: Terry Winograd, Computer Science, Stanford
Oct 15: Ron Kaplan, Xerox PARC
Oct 22: Lotfi Zadeh, Computer Science, UCB
∂04-Sep-85 1408 STUCKY@SU-CSLI.ARPA Dlion-users
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 14:08:06 PDT
Date: Wed 4 Sep 85 13:54:29-PDT
From: Susan Stucky <Stucky@SU-CSLI.ARPA>
Subject: Dlion-users
To: folks@SU-CSLI.ARPA, carol@SU-CSLI.ARPA, bboard@SU-CSLI.ARPA
Dear All,
A week ago, a meeting for Dlion-users and support staff was held at
CSLI. If you are interested, a report on that meeting can be found on
the Dandelion bboard (Heading: Memo). Also, a mailing list,
dlion-users@CSLI, has been established. If you would like to be on that
list, send a request (as usual) to Requests@CSLI. All further
announcements of meetings will go to the users list only, so as to
minimize junk mail.
Cheers.
-Susan
-------
∂04-Sep-85 1736 EMMA@SU-CSLI.ARPA Newsletter September 5, No. 44
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 17:36:32 PDT
Date: Wed 4 Sep 85 17:17:57-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter September 5, No. 44
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
September 5, 1985 Stanford Vol. 2, No. 44
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, September 5, 1985
12 noon TINLunch
Ventura Hall ``Predication, Logical Syntax, and the Type-free
Conference Room Conception of Properties, Relations, and Propositions''
Discussion led by Chris Menzel
2:15 p.m. CSLI Talk
Ventura Hall ``FORK: A Flavor-Based Environment for Object-oriented
Seminar Room Knowledge Representation''
C. Beckstein, G. Goerz,
University Erlangen-Nuernberg, W. Germany
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, September 12, 1985
12 noon TINLunch
Ventura Hall ``Free Word Order in GPSG''
Conference Room by Arnold Zwicky
Discussion led by Hans Uszkoreit, SRI and CSLI
(Abstract on page 2)
2:15 p.m. CSLI Talk
Ventura Hall ``Arithmetical Truth and Hidden Higher-Order Concepts''
Seminar Room Daniel Isaacson, Oxford University
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
!
Page 2 CSLI Newsletter September 5, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ABSTRACT FOR THIS WEEK'S CSLI TALK
``FORK: A Flavor-Based Environment for
Object-oriented Knowledge Representation''
C. Beckstein, G. Goerz, University Erlangen-Nuernberg, West Germany
2:15, Thursday, September 5, Ventura Seminar Room
Most object-oriented extensions of LISP provide only marginal
support for the purpose of knowledge representation. In particular,
there are only poor means---if any---for specifying meta-information
about attributes of objects such as typed domains, methods for
determining values (demons), multiple-valued attributes and explicit
control of inheritance. Furthermore, they usually don't offer
adequate utilities for handling multiple perspectives, retrieving
objects through patterns of characteristic features, and maintaining
structural relations (integrity constraints) in and between objects.
FORK is an attempt to extend Flavors, an object-oriented extension of
LISP, by adding features which are well known from frame-like systems
with the advantage of keeping a systematic distinction between classes
and instances. The procedural knowledge is attached to classes either
in the usual sense of methods as functions or in the form of (forward
chaining) rule sets. In addition, FORK offers a programming
environment to support users in the construction and maintenance of
large, hybrid knowledge bases.
←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S TINLUNCH
``Free Word Order in GPSG''
The ID/LP version of GPSG provides an elegant scheme for describing
certain syntactic phenomena that are usually subsumed under the terms
``free word order'' or ``free constituent order.'' The questions
addressed in this paper are (i) whether (and how) all the variants and
degrees of ordering freedom can be described in the framework and (ii)
whether universal generalizations can be expressed. In this connection,
a universal version of a Pullum-type liberation rule is discussed.
←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S CSLI TALK
``Arithmetical Truth and Hidden Higher-Order Concepts''
Daniel Isaacson, Oxford University
2:15, Thursday, September 12, Ventura Conference Room
The natural numbers can be characterized within a given domain by
the second-order condition that they constitute a minimal collection
closed under a given one to one mapping (succession) and containing an
element (zero) not in the range of that mapping. Peano Arithmetic is
what can be expressed of this characterization by first-order
axiomatization, and is in this sense a natural, conceptually intrinsic
formal system. On the other hand, Godel showed that the truths of
arithmetic are not recursively enumerable, so that any true axiomatic
formal system for arithmetic has proper first-order extensions. It
might seem in this way that no one first-order axiomatic system could
be of intrinsic conceptual importance. This talk will explore
considerations that might resolve the tension between these two
observations, in particular to suggest that possibly Peano Arithmetic
can be considered as complete with respect to genuinely arithmetical
truth, in the sense that perceiving the truth of first-order truths in
the language of arithmetic that are not provable in Peano Arithmetic
must be in terms of higher-order concepts which they code.
!
Page 3 CSLI Newsletter September 5, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
TALK
``Unification-Based Speech Parsing with a Chart''
C. Beckstein, G. Goerz, Univ. Erlangen-Nuernberg, West Germany
2:15, Tuesday, September 10, Ventura Seminar Room
We describe GuLP, a chart parser to be used as a syntactic module
of the Erlangen Speech Understanding System EVAR. Operating with a
unification grammar, GuLP realizes an agenda-based multiprocessing
scheme, which allows the application of various parsing strategies to
fragments of the same utterance in a transparent way. The overall
control mechanism is realized through a general interrupt system. In
order to process speech data, a variety of new features has been
incorporated: in particular the ability to perform incremental
analysis, to do direction independent island parsing, to process gaps
in utterances, and to handle hypothesis scores. Finally, a complexity
estimate and a few experimental results are discussed.
←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
``Discourse-based Interactions of
Four Morphosyntactic Subsystems in Northern Pomo''
Summary of the meeting on Thursday, August 29
Formal theories of discourse representation face the task of
modelling both text-external deixis (expressions anchored to the
context of utterance) and text-internal deixis (e.g., Partee's (1984)
treatment of Reichenbach's `reference time' or Banfield's (1982)
discourse primitive SELF.) Cathy O'Connor discussed these dimensions
in the light of complex interactions of four morphosyntactic
subsystems of Northern Pomo.
(1) Third person, non-clause-bounded reflexives function
logophorically; they establish that the SELF is anchored
to 3rd person.
(2) A possessive prefix found on kinship terms that is
necessarily a bound anaphor is optional outside the
minimal clause containing its antecedent. If SELF is 3rd
person, the anaphoric prefix is obligatory, deictically
linked to this text-internal discourse entity.
(3) An alternation in case-marking for subjects of
unaccusative verbs conveys subjective expression of
internal experience (`I'm feeling really sick') versus
objective reporting (`I'm sick today'). This is normally
limited to 1st person subjects. In discourse contexts
where SELF is 3rd person, the alternation is sanctioned
for 3rd person subjects.
(4) A set of `evidential' verbal inflections, which
indicate utterance-speaker's evidence for the assertion,
display pragmatically motivated co-occurrence restrictions
with respect to the above phenomena.
In light of these findings the relation of logophoricity and
subjunctive mood was discussed. The proposal was made that mood
subordination in a discourse representation is the appropriate domain
for an account of these complex facts. Finally, the problem of
representing (1) through (4) above was discussed, and the notions of
text-internal and text-external deixis were suggested to be necessary
components in a representation of the discourse structures
involved. --Cathy O'Connor
-------
∂04-Sep-85 2123 NEUMANN@SRI-CSLA.ARPA RISKS-1.5, 04 Sep 85
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 21:23:44 PDT
Date: Wed 4 Sep 85 20:32:56-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: RISKS-1.5, 04 Sep 85
To: RISKS: ;
RISKS-FORUM Digest Wednesday, 4 Sep 1985 Volume 1 : Issue 5
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
(Contributions to RISKS@SRI-CSL.ARPA)
(Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
Contents:
The Strategic Defense Initiative (Joseph Weizenbaum)
1.5 million Ford engines need recall? (Hal Murray)
Risks in CAD, etc. (Eugene Miya)
crt & non-crt risks (Mike McLaughlin)
Computerworld... on Union Carbide and NJ false arrests (Charlie Spitzer)
More on false arrests (PGN)
----------------------------------------------------------------------
Date: Wed 4 Sep 85 14:19:15-EDT
From: Joseph Weizenbaum <JOSEPH@MIT-XX.ARPA>
Subject: The Strategic Defense Initiative
To: risks@SRI-CSL.ARPA
Greetings !
I've just been introduced to the RISKS b-board you have undertaken
to maintain. It is a good idea. What stimulates this particular outburst
is John McCarthy's observation that many of the computer people who
maintain that Star Wars can't be made to work for technical reasons, e.g.,
those brought forth by Parnas, are people who have opposed many other
government initiatives. I imagine he means among others the war on Viet
Nam, the MX missile, the ABM initiative of years ago, the administration's
policies vis-a-vis Nicaragua, Cuba and El Salvador, and so on and on.
I confess I've been on what from John's point of view must be characterized
as the wrong side on each of the above controversies. But then John has
been on what I would have to see as the wrong side on all these questions.
Does that relieve me of the obligation to guard my intellectual honesty by
studying his actual arguments ? If so, then the very possibility of dialog
between holders of opposing views becomes impossible.
It is, however, important for people who indeed have a point of view to make
their positions clear, at least not to hide them. Their doing so ought not
to disqualify what they then have to say. For myself, I find it even more
important to actually draw on my quasi pacifist position in arguing about
Star Wars and similar issues and to explicate the connections I make. I do
believe (with Parnas and many others) that the software required simply
cannot be produced to the degree of confidence without which it would be a
meaningless exercise. I don't want to rehash the various technical
arguments here, however. Let me just rest on the well publicized statements
of CPSR and of Parnas. I want to say in addition, however, that I would not
support the SDI initiative even if I thought it to be technically feasible.
In that, John is quite right. I'm afraid that many of the computer people
who rest on the technical arguments alone leave the impression that these
alone constitute their objections to the program. Perhaps that is the
position of many objectors in the computer community. I think, however,
there are many who would join me in resisting the program even if it could
be shown to be technically feasible. I think John is quite right in asking
that that be made explicit where it applies.
This is not the place to air political and ideological positions. For
clarity's sake, I just want to add to the above that I believe it to be
necessary to the survival of us all that we come to some social, political,
cultural accommodation with the rest of the peoples of the world even when,
or especially when, they organize their societies differently than we do
ours. SDI is in the tradition of the great technological fixes which
appear to their authors to relieve them of the responsibility to confront
underlying human problems.
Besides, SDI is a giant step to the further militarization of space and of
our society. I oppose that as well.
Joseph Weizenbaum.
[For those of you just returning from the London 8th International
Conference on Software Engineering, we eagerly await reports on
the panel session of Fred Brooks and Dave Parnas on the feasibility
of SDI from the software engineering point of view alone.
You will find a lengthy special report on "Star Wars" in the
IEEE Spectrum, September 1985. My copy arrived today.
SDI: The Grand Experiment
Part 1 -- Mind-boggling complexity
Part 2 -- Exotic weaponry
Part 3 -- Debating the issues
PGN]
------------------------------
Date: Tue, 3 Sep 85 12:18:36 PDT
From: Murray.pa@Xerox.ARPA (Hal Murray)
Subject: 1.5 Million Ford Engines Need Recall?
To: RISKS@SRI-CSL.ARPA
This morning, my radio said something about a consumer group wanting
Ford to recall 1.5 million engines. Nobody knows what's wrong, but they
are blaming it on the computer. (I didn't get the fine print. I wasn't
awake.) Anybody know if that's the real problem or just a convenient
scapegoat?
[The 4 Sept 85 NY Times has a note on the recall of 454,000
Chevy/Pontiac compacts for corroding pollution control equipment, and
105,000 VW and Audi cars for faulty brake hoses, but nothing on Ford. I
would love to follow up on the 1.5 million Fords, but haven't found
anything yet. PGN]
------------------------------
From: eugene@AMES-NAS.ARPA (Eugene Miya)
Date: 3 Sep 1985 0859-PDT (Tuesday)
To: risks@sri-csl.ARPA
Subject: Risks in CAD, etc.
Something, I have been wondering about, perhaps for future discussion might
concern liabilities of CAD products. It seems more merchandise I purchase
is shoddy, and I am beginning to wonder what some of the consequences of
"making the metal a bit thinner to save.." could be. I realize we are
using CAD and simulation tools to make things more efficient, perhaps the
case of the over efficient engine which flamed out when it flew through rain
[as reposted in SEN, I believe] might be a case in point. What were our
margins of safety in the over-engineering we did in the past? Any studies yet?
Lastly, regarding mail formats: I have run on a gamut of different mailers
[my current one, mh, is not bad], but I can sympathize with those having
problems. It seems Peter's comment about programs was a bit harsh. I used
to read netmail on an IBM machine which concatentated all letters and was
destructive [read once mail].
--eugene miya
NASA Ames Research Center
------------------------------
Date: Wed, 4 Sep 85 18:22:22 edt
From: mikemcl@nrl-csr (Mike McLaughlin)
To: RISKS@SRI-CSL.ARPA
Subject: crt & non-crt risks
It is important we separate crt from non-crt risks. X-rays, color-perception,
& possibly eye fatigue I see as crt related. Posture may be, for a person
tied to the tube for extended periods. Junk food is a non-crt risk, but may
be a denial-of-service risk, if introduced into certain apertures around the
crt. Might also be a hazard to your health, if conductive.
X- & like radiation: I am done producing children, I hope. So does my
wife. Unless radiation reaches carcinogenic levels, I am not concerned for
me. My children all use/will use crts, unless some other display becomes
more economical in the near future. We have 5 children, all of age. I am
concerned about them.
Posture: As an occasional, voluntary, crt user, my posture is my problem.
Take the paper out of my office; or give me a clerical/data entry type job;
then I will see posture as a crt/computer risk. Any obstetrician will worry
about any woman who sits in any one position for long periods. At one point
in one pregnancy my wife had to fly home while I drove alone - solely so she
would not have to sit still too long. (Many years ago I was told that the
blood supply to the brain passed through the peri-anal region. This accounts
for the number of dumb comments and sleeping attendees at various conferences
with inadequate breaks.)
Color-perception: When I go home after dark tonight, the white line will be
pink. No, I'm not on anything. If the screen were pink, the line would be
green. If color sensitivity mattered to me... say, if I performed color-
matching titrations in a hospital, or put color-coded resistors & capicators
into non-ICs, I would worry about color perception.
Considering the liability discussion in V1 #4, perhaps we all should.
In 1956 or 1957 I ran across the proceedings of something-or-other on human
factors in submarine design. Book was pretty beat up, so it had been around
for a while. It cited some *railroad safety* research on color perception.
I think the RR stuff was pre WW-II. Said red & green were neat colors for
signal lights. Also said *yellow symbols on a black background* were the
best combination for a symbolic display... and that the reverse was the next
best. Hence, road signs. Amber screens... ?
Eye-fatigue: Not crt-unique, but... look at anything long enough, your eyes
will tire. Look at anything slightly fuzzy, & your eyes will tire quickly, as
they try to focus on the un-focusable.
Summary: If a tired terminal operator hits a tree on the way home, it might
be due to poor color perception, fatigue due to poor posture (read:
furniture), eye fatigue due to poor colors, poor contrast, fuzzy images. It
might be a financial disaster for the firm that employed said deceased.
Some attorney might look closely into the work situation, and computers
would get a bad name when we are really talking about bad management of the
computer-workplace.
- Mike
------------------------------
Date: Tue, 3 Sep 85 13:07 MST
From: Charlie Spitzer <Spitzer%pco@CISL-SERVICE-MULTICS.ARPA>
Subject: Computerworld Aug 19 articles
To: Risks@SRI-CSL.ARPA
Readers may be interested in 2 articles from Aug 19 Computerworld.
page 6. Union Carbide modeling program given wrong data.
Discusses wrong information about gases input to a program that was
supposed to model gas cloud dispersal. Notable quote: "These programs
have been sold to safety people as opposed to engineers, because [the
systems] provide good [public relations], are attractive visually and
can provide a fairly inexpensive way of dealing with a problem you hope
you'll never have."
page 12. On-line crime suspect system implicated in false arrest.
Discusses case of a NJ woman arrested, strip searched and jailed on two
separate occasions because of inadequate information stored in the NCIC
computer.
charlie
------------------------------
Date: Tue 3 Sep 85 13:56:12-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: More on False Arrests
To: RISKS@SRI-CSLA.ARPA
[For those of you who do NOT read the ACM SIGSOFT Software Engineering
Notes, here are three items taken from my RISKS column in the July 1985
issue on the subject of false arrests. For those of you who have already
read these items, you have come to the last message in this issue and need
read no further.]
In the past quarter year, there were two different stories of people winding
up in jail due to computer-related snafus, and an earlier story that
serendipitously goes along with them.
1. The AnchoRages Of Sin
An article on page 17 of the 15 April 1985 issue of ComputerWorld entitled
``DMV computer error puts innocent motorist in jail''
provides us with another software glitch with harmful side-effects. (Brad
Davis [b-davis@@utah-cs.ARPA] was the first to point this one out to me.)
The article (by Kathleen Burton) details how a mistake in programming the
new Alaskan Department of Motor Vehicles computer system resulted in
a motorist spending a night in a Fairbanks jail. The computer indicated
(erroneously) that C. R. Griffin was driving with a suspended license.
The article also said that only by human intervention were 400 additional
driver's licenses not erroneously suspended. Apparently the database
kept records of all violations in the past @i[five] years, but was supposed
to search only over the last @i[two] years for motorists who should be
suspended. A programmer was quoted as saying that ``the cost of correcting
the mistake [in the program] was insignificant.''
2. Shirley There Must Be a Way Out
And then, on 25 April 1985, the Associated Press ran a story about
congressional hearings on the FBI national crime computer. Two incidents were
included. The first involved an airline flight attendant who was falsely
arrested and detained because of incorrect information in the FBI's national
crime computer. Sheila Jackson Stossier was arrested on 28 October 1983 at the
New Orleans airport, because a woman named Shirley Jackson was wanted by Texas
authorities. She wound up in jail for the night and detained in Louisiana for
five days. She now has an arrest record, and her married name Stossier is
listed in the computer as an alias. Coincidentally, another Shirley (Jones)
was also wrongly arrested because another woman alias Shirley Jones was listed
in the computer -- despite the facts that they had different birthdays, were
six inches apart in height, and 70 pounds in weight. ``Despite this, the
Sheriff's office refused to drop the charges.'' (To make matters worse, it was
later determined that the wanted Shirley was already in jail at the time!)
3. One in Five Warrant Records Were Wrong -- Poor Odds
David Burnham (NY Times News Service) reported the following
related story on 12 Feb 1985.
A Michigan man filed suit charging that he was wrongfully arrested five
times in 14 months after an arrest warrant for a man using his name was
placed in the national computer system of the FBI. The man, Terry Dean
Rogan, charged that four of the arrests occurred after Michigan police had
made an unsuccessful effort to get the warrant changed. Rogan contends and
the police confirm that the man actually being sought was another person
using Rogan's stolen identity and credit cards. Rogan, who is 27 years old,
is not wanted for any crime.
[The rest of the last story (which goes on for another page) is in the July
issue of Software Engineering Notes. It was also BBOARDed earlier, so I
did not think it should be recyled again!]
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂05-Sep-85 1640 EMMA@SU-CSLI.ARPA New project mailing lists
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 5 Sep 85 16:40:49 PDT
Date: Thu 5 Sep 85 16:33:31-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: New project mailing lists
To: folks@SU-CSLI.ARPA
Tel: 497-3479
PROJECT MAILING LISTS (1985-1986)
The following is a list of the new projects with the name of the
project, the person who is in charge, and the mailing address. If you
are in charge of a project, please check the correctness of the
mailing list by either visiting the appropriate file or by using
mmailbox. Please send changes to requests@csli. If you are NOT in
charge of a particular project and you wish to be added, please send
your requests to the appropriate project coordinators.
Linguistic Approaches to Computer Languages. Hans Uszkoreit (done)
LACL=@PS:<CSLI-LISTS>LACL.DIS
Embedded Computation Group. Brian Smith (3 sub groups)
ECG=@PS:<CSLI-LISTS>ECG.DIS
sub 1: Research on Situated Automata. Stan Rosenschein
ROSA=@PS:<CSLI-LISTS>ROSA.DIS
sub 2: Semantically Rational Computer Languages. Curtis Abbott
SRCL=@PS:<CSLI-LISTS>SRCL.DIS
sub 3: Representation and Reasoning. Brian Smith (RRR ?)
(not named yet)
Discourse, Intention, and Action. P. Cohen. done
DIA=@PS:<CSLI-LISTS>DIA.DIS
Rational Agency. Michael Bratman (done)
RATAG=@PS:<CSLI-LISTS>RATAG.DIS
RATIONAL-AGENCY=RATAG
Head-driven Phrase Structure Grammar. I. Sag and T. Wasow (done)
HPSG=@PS:<CSLI-LISTS>HPSG.DIS
Grammatical Theory and Discourse Structures. Joan Bresnan
LFG=@PS:<CSLI-LISTS>LFG.DIS
Phonology and Phonetics. ?Kiparsky
PINTEREST=@PS:<CSLI-LISTS>PINTEREST.DIS
Computational Models of Spoken Language. Withgott
CMOSL=@PS:<CSLI-LISTS>CMOSL.DIS
Finite State Morphology. Karttunen
FSM=@PS:<CSLI-LISTS>FSM.DIS
Visual Communication. Pentland@sri-ai
VISCOM=@PS:<CSLI-LISTS>VISCOM.DIS
A Lexical Initiative. Annie Zaenen (done)
LEXINIT=@PS:<CSLI-LISTS>LEXINIT.DIS
AFT lexical representation Theory. Julius Moravcsik
AFT=@PS:<CSLI-LISTS>AFT.DIS
Foundations of Document Preparation. David Levy.
DOCPREP=@PS:<CSLI-LISTS>DOCPREP.DIS
Foundations of Grammar. Karttunen (done)
FOG=@PS:<CSLI-LISTS>FOG.DIS
Situation Theory and Situation Semantics (STASS) Jon Barwise
STASS
System Development Languages (SDLG) Terry Winograd
SDLG
-------
∂06-Sep-85 0048 NEUMANN@SRI-CSLA.ARPA RISKS-1.6, 06 Sep 85
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 6 Sep 85 00:48:39 PDT
Date: Fri 6 Sep 85 00:04:39-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: RISKS-1.6, 06 Sep 85
To: RISKS: ;
RISKS-FORUM Digest Friday, 6 Sep 1985 Volume 1 : Issue 6
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Joseph Weizenbaum's comments (Dave Parnas)
Good Risks and Bad Risks (Dave Brandin, PGN)
Hot rodding you AT (Dan Bower)
Hazards of VDTs and CRTs (Al Friend)
crt & non-crt risks (Brint Cooper)
The Case of the Broken Buoy (Herb Lin, Matt Bishop)
(Contributions to RISKS@SRI-CSL.ARPA)
(Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Thu, 5 Sep 85 07:28:56 pdt
From: vax-populi!dparnas@nrl-css (Dave Parnas)
To: nrl-css!Neumann@SRI-CSLA.ARPA
Subject: Joseph Weizenbaum's comments <JOSEPH@MIT-XX.ARPA>: sdi]
Although there is a great deal of truth and wisdom in Weizenbaum's
message, I believe that he overlooks the reason that SDI would be
destabilizing and another step in the Arms race. It is not because
of the stated goals of the program (Reagan's March 1983 speech) but because
those goals are not achievable. There would be nothing wrong with rendering
ICBMs and other weapons obsolete. On the contrary, everyone should want to
see every country, city, and town protected by an impenetrable shield that
would free it from the fear of the indiscriminate horror that rained down on
Nagasaki and Hiroshima. It is because the SDIO efforts will not lead to
technology of that sort, that SDI is the things that Weizenbaum says it is.
I agree with Weizenbaum that we need to seek non-technological
solutions. Technology is not likely to provide solutions in a situation
where we oppose a power with equally sophisticated technology.
I believe that SDI is one issue where both disarmament and armament
supporters could agree. Both sides seek peace through different mechanisms,
but neither will find their goals advanced by an untrustworthy "shield".
Dave
------------------------------
Date: Thu 5 Sep 85 11:40:30-PDT
From: Dave Brandin <BRANDIN@SRI-AI.ARPA>
Subject: Good Risks and Bad Risks
To: Neumann@SRI-CSL.ARPA
Peter: I love your material that's being generated and produced, but I note
that it seems to weigh overwhelmingly against the computer. Aren't people
sending you any GOOD stuff? Like with the aid of a computer, 27 lives were
saved, etc.? Like using the new NEC fingerprint computer, they were able to
match the Stalker's finger-prints in 3 minutes, etc? Maybe you need a Call
for Good News?
Dave
------------------------------
Date: Thu 5 Sep 85 23:32:45-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Good Risks and Bad Risks
To: RISKS@SRI-CSLA.ARPA
Cc: BRANDIN@SRI-AI.ARPA
Today's SF Chronicle had a nice article on "Computer Holds Promise in
Diagnosing Heart Disease", in greatly reducing the number of false
negatives. But even there are significant risks. Suppose you or your
doctor trusts the computer program more because it indeed has fewer false
negatives, and now you produce a false negative. We are back to the case of
the woman who killed her daughter and tried to kill herself and her son
because the computer program had falsely produced an "incurable"
diagnosis. (See the July 85 issue of Software Engineering Notes.)
Well, in the first issue of RISKS I recall saying there has got to be more
to this forum than just pointing out negative things. I noted hope from the
research community, although one of the agonizing things that we have
observed in the ACM Special Interest Group on Software Engineering (SIGSOFT)
is the enormous gap between the research community and what is actually
being done in practice. For critical systems, the ordinary software
development techniques are simply not good enough.
Yes, we should of course point out successes. For example, the Shuttle
project has had many -- along with its much more visible problems.
Peter
------------------------------
Date: Wed, 4 Sep 85 14:41:38 EDT
From: Dan←Bower%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
To: RISKS@SRI-CSLA.ARPA
Subject: Hot rodding you AT
In a recent issue of PC Magazine, Peter Norton espoused the idea of
substituting a faster clock chip to enhance performance. Now, according
to the folk on the Info-IBM PC digest, this may create problems. An
off the shelf PC AT is composed of components guaranteed to work to
IBM spec, e.g. 6 Mhz. If I increase the clock rate, then the whole
rest of the machine has to be up to snuff. If not, a part dies and
I pay a nasty repair bill.
Now if I took Mr. Norton's word as gospel, swapped chips and set
my PC AT on fire, would he be liable? How about the publisher?
------------------------------
Date: Thu, 5 Sep 85 15:23:05 edt
From: friend@nrl-csr (Al Friend, Space and Naval Warfare Systems Command)
To: risks@sri-csl
Subject: Hazards of VDTs and CRTs
When evaluating the risks associated with various forms of technology
it is sometimes useful to have in hand the available data.
The Food and Drug Administration published a study in 1981:
An Evaluation of Radiation Emission
from
Video Display Terminals
HHS Publication FDA 81-8153
The ionizing, optical, RF and acoustic radiation from a number of
terminals was measured. I will briefly quote some of the conclusions
of this study.
For ionizing radiation:
3.5 DISCUSSION
Sufficient research information is available to estimate a range of
risks of injury from ionizing radiation exposure. Delayed disease,
such as heritable mutation or cancer, usually forms a basis for the
estimation, expressed in terms of the instances of the effect per
person per unit of radiation (rad,rem, or R). The risk estimates
form a basis for radiation protection guidelines.
For a VDT operator, the radiation protection guideline for
individuals in the general population is appropriate. The guideline
-- 500 millirem per year -- is for man-made radiation exposures
excluding medical use. For both normal and Phase III operating
conditions, the likely emission from a VDT is 0.1 mR per hour or less.
Terminals capable of exceeding the 0.5 mR per hour regulatory limit
receive special attention (see Section 3.2, above). With assumptions
of 6 hours of viewing per day, 5 days per week for 50 weeks per year,
the annual radiation dose to an individual 2 inches from the front
surface of a screen emitting 0.1 mR per hour would be 150 millirem.
Note that 2 inches is an unrealistically short viewing distance; as
one moves further away from the screen, the radiation exposure
decreases correspondingly.
For RF radiation:
4.5 DISCUSSION
Research information on bioeffects for the frequency range 15kHz to
125 kHz is lacking, so empirical estimates of injury are not possible.
However, the radiation in this frequency region interacts only
slightly with the human body, so that significant biological effects
are unlikely. At the present time, no standard or guideline has been
adopted in the U.S. for grequencies below 10 MHz.
For ultrasound radiation:
5.4 DISCUSSION
When airborne ultrasound impinges on human skin less than 1 percent
is absorbed, the remainder being reflected. The ear, however, is an
efficient coupler of acoustic energy from air into the human body.
Therefore, investigations of the biological effects of ultrasound
levels much higher than those found in the VDT survey have included
temporary threshold shifts in hearing (6). So-called subjective
effects have also been associated with high levels of ultrasound
exposure, and include fatigue, headache, tinnitis, instability, a
"fullness" in the ear, and nausea. One report (7) tentatively
associates the subjective effects with audible high frequency
components of sonic radiation. The studies were performed in the
exposure range 70-120 dB in an industrial setting, and at 150 dB.
No long term effects or delayed injuries are known.
No formal standard for ultrasound exposure presently exists in the
U.S. Among several voluntary guidelines available, the
recommendations of W.I. Acton of the United Kingdom were used to
compare the VDT results, because they are the most conservative in
this frequency range. The highest acoustic measurement obtained
from a VDT in this study was 68 dB, well below Acton's guideline
of 75 dB, and well below the energies associated with biological
effects.
For "ergonomic" factors:
7. CONCLUSIONS AND RECOMMENDATIONS
*****
*****
The word processing field has expanded much faster than has the
understanding of its impact on people who use VDTs. The impact
may be felt in areas such as employee morale, compensation,
work hours, and work conditions. We suggest that work conditions
be given serious conisideration as the primary cause of VDT-user
complaints. The problem is not simple, however. An extensive
review of stress factors in the word processing work area (10)
identified five separate factors that contribute to fatigue:
vision, posture, environment, task organization, and higher
order items such as disease susceptibility. As early as 1976,
it was recognized that glare (room lighting reflecting from the
VDT face plate), work position, ambient noise, and work duration
(absence of breaks) could be the most important factors
influencing the VDT worker's health (11). The parallel
between the 1976 and 1979 studies is sufficiently strong for
us to suggest that efforts expended to reduce stress caused
by these factors would also reduce the adverse impact on
health.
The above quotes from the FDA document are some of its most important
conclusions. References to additional work are provided in the
document. There has been further work since the time of this report
(1981). I do not have immediate access to these later references. I
believe they tend to bear out the conclusions of this report.
From conversations with those closer to this field than I, I get the
impression that one of the major stress factors in commercial word
processing operations is the highly regimented work situation, and the
possibility of being fired, if the operator does not turn out a certain
minimum amount of mistake free work per hour.
------------------------------
Date: Thu, 5 Sep 85 11:55:42 EDT
From: Brint Cooper <abc@BRL.ARPA>
To: mikemcl@nrl-csr.ARPA
cc: RISKS@SRI-CSL.ARPA
Subject: Re: crt & non-crt risks
Many of the crt/workplace issues you raise are shared by another group
whose members are quite diverse in their use of crt terminals:
secretaries.
I know this is not quite the correct forum, but workplace rules and
legislation designed to "protect" users of terminals from problems of
posture, vision, and stress should consider this forgotten group of
workers as well. Their problems are nearly the same.
Brint
------------------------------
Date: Thu, 5 Sep 85 17:06:21 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
Subject: The Case of the Broken Buoy
To: mab@RIACS.ARPA
cc: LIN@MIT-MC.ARPA, risks@SRI-CSL.ARPA
In response to:
Dave Curry's right. I remember reading a newspaper report which
said, in essence, that the NWS/NOAA lost because it had failed to
predict the storm. I didn't believe it, so I read on, and the report
said that since they had known of a broken buoy, had failed to repair
it (I think it had been broken for several months), and therefore failed
to get the information needed to give a warning, they were guilty of
negligence and had to pay. Quite a far cry from what the story had
begun as!
On the other hand, the NWS also said that even if the buoy had been
alive at the time, they would not have predicted the storm. This
isn't to defend sloppy journalism, just to point out that the
newspaper was in essence correct in this instance.
------------------------------
Date: 5 Sep 1985 2049-PDT (Thursday)
From: Matt Bishop <mab@riacs.ARPA>
Organization: Research Institute for Advanced Computer Science
Address: Mail Stop 230-5, NASA Ames Research Center, Moffett Field, CA 94035
Phone: (415) 694-6363 [main office], (415) 694-6921 [my office]
To: Herb Lin <LIN@MIT-MC.ARPA>
Cc: risks@SRI-CSL.ARPA
Subject: Re: The Case of the Broken Buoy
Did the NWS say that (i.e., even if the buoy had been alive at the time,
they could not have predicted the storm) in testimony, or after the verdict?
If after the verdict, no comment. But if as testimony, Herb, the jury (or
judge) apparently didn't believe the NWS testimony. If you believe the NWS
claim, the headline was correct, but it's unfair to say the court ruled that
way when it explicitly based its ruling on negligence.
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂08-Sep-85 0149 NEUMANN@SRI-CSLA.ARPA RISKS-1.7, 08 Sep 85
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 8 Sep 85 01:49:26 PDT
Date: Sun 8 Sep 85 00:37:04-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: RISKS-1.7, 08 Sep 85
To: RISKS: ;
RISKS-FORUM Digest Sunday, 8 Sep 1985 Volume 1 : Issue 7
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
The risks of not using some technology (John McCarthy)
More on SDI (Joseph Weizenbaum)
SDI reliability (Martin Moore)
Re: Hazards of VDTs and CRTs (Bernie Elspas)
Viruses, Trojan horses, and worms (Fred Hapgood, PGN)
Re: The Case of the Broken Buoy (Herb Lin, Matt Bishop)
Re: Hot rodding you AT (Keith F. Lynch)
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: 07 Sep 85 1329 PDT
From: John McCarthy <JMC@SU-AI.ARPA>
Subject: The risks of not using some technology
To: risks@SRI-CSL.ARPA
The problem with a forum on the risks of technology is that
while the risks of not using some technology, e.g. computers, are
real, it takes imagination to think of them. A further problem
with newspaper, magazine and TV discussion of technology is that
journalists and free-lance writers tend to run in intellectual
mobs. This biases the discussion for everyone, especially when
the same journalists read each others writings and call it public
opinion. Here are some illustrations.
1. Suppose some organization manages to delay interconnecting
police data systems on some specious civil liberty grounds.
Suppose some wanted murderer is stopped for a traffic offense
but not arrested, because he is wanted in a jurisdiction not
connected to the computer system used by the police officer.
He later kills several more people. The non-use of computers
will not be considered as a cause, and no-one will sue the
police for not interconnecting the computers - nor will anyone
sue the ACLU. The connection will not even be mentioned in
the news stories.
2. No relative of someone killed on U.S. 101 during the 10 years
the Sierra Club delayed making it a freeway sued the Sierra Club.
3. No non-smoker who dies of lung cancer in an area newly polluted by
wood smoke will sue the makers of "Split wood not atoms" bumper
stickers.
***
Based on past experience, I expect this question to be ignored, but here's
one for the risk-of-computers collectors. Is a risk-of-computers
organization that successfully sues to delay a use of computers either
MORALLY or LEGALLY LIABLE if the delay causes someone's death? Is there
any moral or legal requirement that such an organization prove that they
have formally investigated whether their lawsuit will result in killing
people? As the above examples indicate, the present legal situation
and the present publicity situation are entirely unsymmetric.
***
Here's another issue of the social responsibility of computer
professionals that has been ignored every time I have raised it.
The harm caused by tape-to-tape batch processing as opposed to on-line
systems.
From the earliest days of commercial computing people have complained
about seemingly uncorrectable errors in their bills. The writers
don't know enough to connect this with the use of tape-to-tape
batch processing. Under such a system when a customer complains,
the person who takes the complaint fills out a form. A key puncher
punches the form on a card. At the next file-update, this card
goes to tape, and a tape-to-tape operation makes the correction.
If there is any error in the form or in the key punching, the
correction is rejected, and the customer gets the wrong bill again.
On-line systems permit the person who takes the complaint to make
the correction immediately. Any errors in making the correction
show up immediately, and the person can keep trying until he gets
it right or ask for help from a supervisor. Not only is the customer
better off, but the complaint-taker has a less frustrating job.
My own experience with the difference occurred in 1979 when my
wallet was stolen, and I had to tell American Express and Visa.
American Express had an on-line system, and the person who took
the call was even able to give me a new card number on the spot.
The Visa complaint-taker had to look it up on a micro-fiche file
and call back, and still they got it wrong. They gave me a new
account number without cancelling the old one.
Perhaps this issue is moot now, but I suspect there are still
many tape-to-tape systems or systems using modern equipment that
still emulate the old systems. Shouldn't computer professionals
who pretend to social responsibility take an interest in an
area where their knowledge might actually be relevant?
Once upon a time, beginning perhaps in the middle nineteenth
century, scientific organizations were active in pressuring
government and business to use new technology capable of
reducing risk and promoting the general welfare. I have in
mind the campaigns for safe water supplies and proper sewage
disposal. Here's a new one that involves computer technology.
Theft can be reduced by introducing the notion of registered
property. When you buy a television, say, you have the option
of buying a registered model, and the fact that it is registered
is stamped on it. Whenever someone buys a piece of used registered
property he has the obligation of telephoning the registry to
check whether the property with that serial number has been reported
stolen and recording his ownership. Repairmen are also obliged
to telephone either by voice or by keyboard.
Unfortunately, too many computer people imagine their social
responsibility to consist solely of imagining risks.
------------------------------
Date: Sat 7 Sep 85 16:30:11-EDT
From: Joseph Weizenbaum <JOSEPH@MIT-XX.ARPA>
Subject: More on SDI (reply to comments on RISKS-1.5 statement)
To: Neumann@SRI-CSL.ARPA
I've received a number of responses to the remark I made that I would not
support the SDI program even if I thought it could be made to work. I have
the feeling that, if I try to respond globally, a full blown debate
may ensue. That I really don't want to conduct with the bboard as the
medium of expression. Nevertheless, I feel obligated to say just a few
words in an attempt to clarify some ideas that have probably been
misunderstood.
I said that my attitude derives from what I called a "quasi pacifist"
position. One writer thought that pacifists are opposed to all forms of
self defense. Actually pacifists are often the first to come to the
defense of justice being trampled. But the form of their resistance to
wrongs is non-violent. It ought also not to be confused with "passive"
resistance - Gandhi often pointed out, usually by his own example, that there
is nothing passive about non-violent resistance. My use of the term "quasi
pacifist" also elicited comment: Am or am I not a pacifist? Let me say I
strive to become a pacifist, to grow up to be one. One isn't an adult by
virtue of merely wishing or claiming to be one. Just so with being a
pacifist. I am still far from the goal.
People apparently believe that, were the SDI technically feasible there
could be no reasonable objections to its development and deployment.
Wouldn't it be comforting if every region, every city and village in
America had, so to speak, an invisible shield over it which guarded against
the invasion of hostile missiles, they ask. Speaking entirely in practical
terms, I would remind them that every year tons (perhaps kilotons) of
marijuana are smuggled past the U.S. Coastguard and the custom service.
Now that technical progress allows the construction of nuclear "devices"
smaller than a moderately sized overnight bag, a determined enemy could
destroy American cities without "delivering" war heads by air mail at all !
If I were responsible for national security, I would worry if, a few days
before the President's traditional State of the Union message, usually
delivered to the assembled leadership of all three branches of our
government, some foreign embassy evacuated all its personel. Perhaps a
nuclear device of moderate size had made its way to Washington and is about
to decapitate the government. We can no more bring peace to this globe by
putting impenetrable domes over nations than we can halt the violence in
our cities by providing everyone with bulletproof clothing. Human problems
transcend technical problems and their solutions.
But suppose we could solve the smuggled bomb problem.
I would still oppose SDI.
SDI is an attempt at a technological solution to problems which have
their roots in and are social, political, economic, cultural, in other
words, human problems. It is an attempt to find solutions under the the
light provided by technology when in fact we know them to reside only in
the human spirit. That is what guarantees the failure of SDI more surely
than its complexity or the impossibility of its being tested.
Beyond all that is the fact that we live in a world of finite resources.
The scarcest resource of all is human talent and creativity. The military
already commands the time and energy of most American scientists and
engineers. Money is another scarce resource on which the military has first
call. On the other hand, social services of all kinds
are being cut back. Meanwhile the country faces social problems
of horrendous dimensions: There is massive, deep poverty in the land.
Adequate health care is beyond the reach of millions of citizens and
ruinously expensive for many more millions. The schools are spewing out "a
rising tide of mediocrity" while a huge fraction of our youth is functionally
illiterate. The conditions that brought on the riots in American cities,
for example in Watts, have never been attended to - they silently tick
away, time bombs waiting to go off.
When resources are limited they must be distributed on the basis of a
widely based consensus on priorities. To silently consent to lowering
still further the priorities our society assigns to the people's health and
education in favor of spending the billions of dollars required above and
beyond the already huge military budget for only the first stages of SDI,
is, it seems to me, to condone the continuing impoverishment and
militarization of not only America, but of the whole world. Ever more
scientists and engineers will be occupied with military work. Ever more
industrial workers of many different kinds will be enmeshed in the
militarized sectors of society by, for example, being required to have
military security clearances. There is a danger that, in the process of the
growing militarization of society, a certain threshold, hard to define but
terribly real, will be crossed and that, once crossed, there will be no ready
road back to a civilian society.
Joseph Weizenbaum
------------------------------
Date: Fri, 06 Sep 85 14:54:52 CDT
From: mooremj@EGLIN-VAX
Subject: SDI reliability
To: risks@sri-csl
[Peter, I have also posted this to SOFT-ENG. If you think the duplication
is reasonable, please include it in RISKS as well. -- mjm]
I've been thinking about the SDI system and how it will be implemented.
Specifically, I've been looking at a system composed of N independent
platforms, each of which performs its own detection, decision making, and
response. Given this type of system, we can reach a few conclusions about
the reliability of the whole system, based on the reliability of a single
platform. I've crunched a few numbers: nothing profound, just some basic
statistics.
Definitions:
1. A "false positive" is an attack response by a platform when such a response
is not justified.
2. A "false negative" is failure of a platform to attack when an attack
response is justified.
Let's look at the false positive case first. How likely is the system to
experience a false positive, based on the probability for each platform?
N: 50 100 200 500 1000 2000
Pp: +------------------------------------------------------------------
1.000E-12 | 5.000E-11 1.000E-10 2.000E-10 5.000E-10 1.000E-09 2.000E-09
1.000E-11 | 5.000E-10 1.000E-09 2.000E-09 5.000E-09 1.000E-08 2.000E-08
1.000E-10 | 5.000E-09 1.000E-08 2.000E-08 5.000E-08 1.000E-07 2.000E-07
1.000E-09 | 5.000E-08 1.000E-07 2.000E-07 5.000E-07 1.000E-06 2.000E-06
1.000E-08 | 5.000E-07 1.000E-06 2.000E-06 5.000E-06 1.000E-05 2.000E-05
1.000E-07 | 5.000E-06 1.000E-05 2.000E-05 5.000E-05 1.000E-04 2.000E-04
1.000E-06 | 5.000E-05 1.000E-04 2.000E-04 4.999E-04 9.995E-04 1.998E-03
1.000E-05 | 4.999E-04 9.995E-04 1.998E-03 4.988E-03 9.950E-03 1.980E-02
1.000E-04 | 4.988E-03 9.951E-03 1.980E-02 4.877E-02 9.517E-02 1.813E-01
1.000E-03 | 4.879E-02 9.521E-02 1.814E-01 3.936E-01 6.323E-01 8.648E-01
Pp is the probability that a given weapons platform will experience a false
positive. N is the number of platforms in the system. The entries in the
table give the probability that a false positive will occur on at least one
platform (and one may be enough to start a war.) For example, if there are
1000 platforms, and each one has a one-millionth (1.000E-6) probability of
experiencing a false positive, then the cumulative probability that some
platform will do so is 9.995E-4, or .09995%. Looking at the table, I'd say
the numbers in the lower right corner are rather disquieting, to say the least.
Now let's look at the false negative case. The table is structured a little
differently here. In the false positive case, a single failure is disastrous;
in the false negative case, it's not. The probability of a false negative
should be many orders higher than that of a false positive, simply because the
protections against a false positive will actually enhance the chances of a
false negative. This table deals with a 100-platform system (that being the
most my binomial coefficient routine can handle).
Pn: .001 .01 .05 .1 .2 .3 .4 .5
N: +---------------------------------------------------------------
30 | 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000
35 | 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.9991
40 | 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.9824
45 | 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.9991 0.8644
50 | 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.9832 0.5398
55 | 1.0000 1.0000 1.0000 1.0000 1.0000 0.9995 0.8689 0.1841
60 | 1.0000 1.0000 1.0000 1.0000 1.0000 0.9875 0.5433 0.0284
65 | 1.0000 1.0000 1.0000 1.0000 0.9999 0.8839 0.1795 0.0018
70 | 1.0000 1.0000 1.0000 1.0000 0.9939 0.5491 0.0248 0.0000
75 | 1.0000 1.0000 1.0000 1.0000 0.9125 0.1631 0.0012 0.0000
80 | 1.0000 1.0000 1.0000 0.9992 0.5595 0.0165 0.0000 0.0000
85 | 1.0000 1.0000 1.0000 0.9601 0.1285 0.0004 0.0000 0.0000
90 | 1.0000 1.0000 0.9885 0.5832 0.0057 0.0000 0.0000 0.0000
95 | 1.0000 0.9995 0.6160 0.0576 0.0000 0.0000 0.0000 0.0000
100 | 0.9048 0.3660 0.0059 0.0000 0.0000 0.0000 0.0000 0.0000
Pn is the probability that a given platform will experience a false negative.
N is the minimum number of platforms (out of 100) which respond correctly.
The table entries give the probability that at least N platforms respond
correctly. For example, if the probability of a given platform experiencing
a false negative is 0.1 (10%), then the probability is 99.92% that at least
80 out of 100 platforms respond correctly, 58.32% that at least 90 respond
correctly, and so on.
Some of the Pn's and Pp's may strike you as much too high. I don't think so.
The two tables were constructed on the simplifying assumption that Pn and Pp
are constants; actually, they are reliability functions. The longer a platform
is in service, the more likely it is to malfunction. If we assume that the
time-to-failure rate of a platform is some form of Weibull distribution
[a*B*t**(B-1) * e**(-a*t**B)], then the reliability function is given by Z(t)
= a*B*t**(B-1). I did not use this in constructing the tables in order to
keep from drowning in figures, and because I don't really know how to choose
a, B, and unit t, until we get a history of actual performance (and by then it
may be too late...) Suggestions are welcome.
Martin Moore (mooremj@eglin-vax.arpa)
------------------------------
Date: Fri 6 Sep 85 15:45:16-PDT
From: Bernie <ELSPAS@SRI-CSLA.ARPA>
Subject: Hazards of VDTs and CRTs
To: RISKS@SRI-CSLA.ARPA
RE: RISKS contribution from friend@nrl-csr (Al Friend, Space and
Naval Warfare Systems Command); RISKS-1.6
The 1981 FDA study cited by Friend probably contains much useful (albeit
rather "soothing") information about VDT *radiation* hazards (ionizing,
RF, and acoustic). One should observe carefully, however, that the
quoted material fails to mention other kinds of hazards, nor does its
title reflect any others. One should, therefore, not assume that
*radiation* hazards are the whole story for VDTs. I would have felt
more relieved at the data presented had it included some other, more
obvious, risk factors such as visual effects.
In particular, recent studies show that at least two visual effects may
be quite important as factors producing severe eye fatigue. The first,
visual flicker (resulting from the screen refresh rate), is probably
well understood (from extensive psychovisual experimentation in
connection with TV viewing). The higher screen refresh rates used on
some computer graphic displays seem to minimize this problem. However,
60 fields/sec (50, in Europe) is standard for most personal computers.
[Flicker depends on many factors: rate, ambient light, screen contrast,
brightness, subject motion, color, etc. More seems to be known about the
conditions for minimal *perceptible* flicker than about those that can
produce visual fatigue, eyestrain, headaches, etc. Also, there is a
fairly large variation among different subjects even for minimal
perceptible flicker, and flicker may be noticeable (and annoying) in
the "fringe visual field" (off to the side) even when it is not detectable
for the object directly ahead.]
The second factor is connected with the fact that the human eye is not
chromatically corrected, i.e., its focal accommodation is different for
different colored objects. The result is that when the eye is focused
correctly on a blue object, a nearby red object will be slightly out of
focus. One study [1] indicates that the discrepancy is about 0.5
diopters (for a viewing distance of 50 cm). According to one report
I've seen (sorry, I can't find the reference!), this means that in a
multicolored display the eye will automatically be making rapid
focus adjustments in scanning the screen. Even worse, the effect can
also exist in some monochrome displays, i.e., where the character
color (white, say) is achieved by a mixture of two differently colored
phosphors separated substantially in wavelength. In the latter situation
it appears that (at least for some people) the eye may undergo extremely
rapid focus oscillations in the futile attempt to bring both component
colors into focus. Quite understandably this may result in severe eye
fatigue, even though the subject may not be consciously aware of what
is happening. This occurs mostly when the two phosphors radiate nearly
pure spectral lines. Single-phosphor displays and those where the
component pure colors are close enough in wavelength seem not be prone
to this disturbing effect. I recall seeing the statement that AMBER
displays are not objectionable for this reason, and that one nation
(Sweden or West Germany, I think) has specified amber displays for
extended-time industrial use.
It seems to me that the chromatic refocusing effect is probably the more
serious of the two cited, especially on high resolution displays. The
fact that it seems not to have been noticed on conventional (analog)
color TV displays may be accounted for by their relatively poor
resolution (low bandwidth). Thus, the brain expects to see a sharper image
on a high-resolution (RGB) display than on a conventional TV (where
everything--especially the reds and oranges--is pretty blurred anyway).
In summary, in concentrating on the "serious" potential hazards of
X-rays, etc., from VDTs, we should not thereby overlook the more obvious
factors concerned with the visual process itself.
1. G.M. Murch, "Good color graphics are a lot more than another pretty
display," Industrial Research and Development, pp. 105-108 (November
1983).
Bernie Elspas
[Material inside [...] may be deleted at editor's option. Bernie]
[The editor decided to leave it in. PGN]
------------------------------
Date: Fri 6 Sep 85 22:55:13-EDT
From: "Fred Hapgood" <SIDNEY.G.HAPGOOD%MIT-OZ@MIT-MC.ARPA>
Subject: Viruses, Trojan horses, and worms
To: RISKS@SRI-CSL.ARPA
I would like to see a discussion by the members of this list
of the degree to which computer users, whether individuals or
organizations, are vulnerable to worms and Trojan Horses. These
terms, which first appeared in this list in #3, refer to programs
designed to inflict some form of unpleasantness on the user, up to
and including the destruction of the system. Typically they erase
all files in reach. I have read discussion, in Dvorak's column in
*Infoworld*, of the possibility that such programs might modify the
operating system as well such that when the unfortunate user tries
to restore the destroyed files from backup disks, those too would be
erased. One can also imagine, vaguely, programs that are insidious
rather than calamitious, that introduce certain categories of error,
perhaps when strings of numbers are recognized. These might be able
to do even more damage over the long run.
There are two issues with these programs. The first is what
they might do, once resident. The second is the nature of the
vector, to borrow a medical term. Worms can be introduced directly,
by 'crackers', or surreptiously, by hiding them inside a legitimate
program and waiting for an unsuspecting user to run that program on
his system, thus activating the 'Trojan Horse'. The article cited in
#3 had to do with a program camouflaged as a disk directory that was
circulated on the download BBSs. One could imagine a spy novel
devoted to the theme: perhaps it was the KGB, and not Ben Rosen, who
provided the money to launch Lotus. Inside every copy of 1-2-3 and
Symphony is a worm which, every time it is run, checks the system
clock to see if it was later than, say, October 1, 1985. On that
date the commercial and industrial memory of the United States dies.
The CIA suspects something is up, but they don't know what.
Unfortunately the director of the team working on the problem is a
KGB mole. Fortunately there is this beautiful and brilliant female
computer genius ...
Anyway, I have a specific question: can anyone imagine a
circumstance in which a program appended to a piece of text in a
system could get hold of the processor? It would appear not, which
is a good thing, because if such circumstances did exist, then it
would become possible to spread worms by pigyybacking them on a
telecommunicated piece of text. The right piece of text -- some
specialized newsletter, or even a crazily attractive offer from
a 'Computer Mall'-- might find itself copied into thousands of
systems. But I am not a technical person, and cannot establish
to my satisfaction that such an eventuality is truly impossible.
Is it?
------------------------------
Date: Sat 7 Sep 85 23:59:24-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Re: Viruses, Trojan horses, and worms
To: SIDNEY.G.HAPGOOD%MIT-OZ@MIT-MC.ARPA
Cc: RISKS@SRI-CSLA.ARPA
Absolutely not. It is quite possible. However, I can assure you that
this issue does not now include a virus -- although some message systems
tend to permit you to edit a message before resending it, with no
indication that it has been altered. Thus, even in the presence of all
of those routing headers, you can never be sure you really have picked
up or been forwarded the original message. The example of squirreled
control characters and escape characters that do not print but cause
all sorts of wonderful actions was popular several years ago, and
provides a very simple example of how a message can have horrible
side-effects when it is read.
Worms, viruses, and Trojan horses from their technical aspects are probably
best discussed elsewhere -- e.g., in SECURITY@RUTGERS. (See also Fred
Cohen's paper in the 7th DoD/NBS Computer Security Conference in 1984.)
From the RISKS point of view, they are definitely important to this forum
-- and they present a very serious risk to the public. PGN]
------------------------------
Date: Fri, 6 Sep 85 16:01:38 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
Subject: The Case of the Broken Buoy
To: mab@RIACS.ARPA
cc: risks@SRI-CSL.ARPA
Did the NWS say that (ie, even if the buoy had been alive at
the time, they could not have predicted the storm) in testimony,
or after the verdict? If after the verdict, no comment.
I believe it was during testimony, but I am not certain.
But
if as testimony, Herb, the jury (or judge) apparently didn't
believe the NWS testimony. If you believe the NWS claim, the
headline was correct, but it's unfair to say the court ruled
that way when it explicitly based its ruling on negligence.
But it is not clear that the court understands that the significance
of "missing data" is context-dependent. Sometimes it matters, and
sometimes it doesn't. This is a point that non-scientists have a very
hard time understanding.
I am not defending the NWS; they should have repaired the buoy. But
given limited resources, how are they to set priorities in deciding
what to repair first? The implications of the verdict are to me
frightening, placing NWS and all other similar organizations in a
double bind: all equipment must be functional even when they don't
have sufficient dollars to keep it that way.
------------------------------
Date: 6 Sep 1985 1359-PDT (Friday)
From: Matt Bishop <mab@riacs.ARPA>
To: Herb Lin <LIN@MIT-MC.ARPA>
Cc: risks@SRI-CSL.ARPA
Subject: Re: The Case of the Broken Buoy
But it is not clear that the court understands that the significance
of "missing data" is context-dependent. Sometimes it matters, and
sometimes it doesn't. This is a point that non-scientists have a very
hard time understanding.
At this point I'm going to bow out of the discussion, since I am not
familiar enough with the decision to know if the court understood that
point. The NWS certainly should have made its position very clear, so
the court could make an informed decision (about whether or not
negligence was involved.)
------------------------------
Date: Fri, 6 Sep 85 09:24:39 EDT
From: Keith F. Lynch <KFL@MIT-MC.ARPA>
Subject: Re: Hot rodding you AT
To: RISKS@MIT-MC.ARPA
Date: Wed, 4 Sep 85 14:41:38 EDT
From: Dan←Bower%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
Subject: Hot rodding you AT
In a recent issue of PC Magazine, Peter Norton espoused the idea of
substituting a faster clock chip to enhance performance. Now, according
to the folk on the Info-IBM PC digest, this may create problems. An
off the shelf PC AT is composed of components guaranteed to work to
IBM spec, e.g. 6 Mhz. If I increase the clock rate, then the whole
rest of the machine has to be up to snuff. If not, a part dies and
I pay a nasty repair bill.
Now if I took Mr. Norton's word as gospel, swapped chips and set
my PC AT on fire, would he be liable? How about the publisher?
I doubt this would break anything. The machine would simply cease
working above a certain speed, and resume working below that speed.
I know of a couple people who have done this on APPLE computers,
tried various speeds so as to run their machine at the highest speed
it will go.
Also, I once did the same thing with a synchronous link, i.e. hooked
up an external clock and cranked it up to the highest speed it would
work reliably at.
Also, I have done this with my Hayes modem. The standard duration for
touchtone pulses is 70 ms. The phone system here will accept as short
at 38 ms.
...Keith
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂08-Sep-85 1840 NEUMANN@SRI-CSLA.ARPA RISKS-1.8, 08 Sep 85, 2nd issue today!
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 8 Sep 85 18:40:18 PDT
Date: Sun 8 Sep 85 16:21:08-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: RISKS-1.8, 08 Sep 85, 2nd issue today!
To: RISKS: ;
RISKS-FORUM Digest Sunday, 8 Sep 1985 Volume 1 : Issue 8
***** NOTE: Second Issue Today *****
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Risks of omission (Nancy Leveson, Nicholas Spies, Herb Lin, Dave Parnas)
Hot rodding you AT and the weather (John McCarthy)
Re: Good Risks and Bad Risks (Brint Cooper)
SDI reliability (Herb Lin)
Viruses, Trojan horses, and worms (Lin and Neumann, 2 each -- his own?)
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: 08 Sep 85 14:58:56 PDT (Sun)
From: Nancy Leveson <nancy@uci-icsd>
To: RISKS@SRI-CSLA.ARPA
Subject: Risks of omissions
I had not intended to get involved in the RISKS Forum discussions, but
despite my great respect for John McCarthy's accomplishments, I just cannot
let his latest message (RISKS-1.8, Sept. 8) pass without comment.
Some important points that need to be considered:
1) Nothing is completely safe. All activities and technologies involve
risk. Getting out of bed is risky -- so is staying there. Nitrates have
been shown to cause cancer -- not using them may mean that more people will
die of food poisoning.
2) Technology is often introduced for the mere sake of using the "latest,"
sometimes without considering the fact that the situation may not really be
improved. For example, everybody seems to be assuming lately that machines
will make fewer mistakes than humans and there is a frantic rush to include
computers and "artificial intelligence" in every new product. Where speed
is the determining factor, then they may be right. Where intelligent
decision making in the face of unforeseen situations and factors is
foremost, then it may not be true. Some electro-mechanical devices may be
more reliable than computers. Since I am identified with the area of
"software safety," I am often consulted by those building safety-critical
software systems. It is appalling how many engineers insist that computers
do not make "mistakes" and are therefore safer than any other human or
electro-mechanical system. We (as computer scientists) have often been
guilty of condoning or even promoting this misconception. Often it seems
that the introduction and use of non-scientific and misleading terminology
(e.g. "intelligent," "expert", "proved correct") has far outstripped the
introduction of new ideas.
3) Technology introduced to decrease risk does not always result in
increased safety. For example, devices which have been introduced into
aircraft to prevent collisions have allowed reduced aircraft separation
with perhaps no net gain in safety (although there is a net gain in efficiency
and profitability). There may be certain risk levels that people are
willing to live with and introducing technological improvements to reduce
risks below these levels may merely allow other changes in the system which
will bring the risks up to these levels again.
4) Safety may conflict with other goals, e.g. productivity and efficiency.
Technology that focuses on these other goals may increase risk.
John McCarthy suggests that people ignore the risks of not using technology.
I would suggest that it is not that these risks are ignored, but that they
are known and we have learned to live with them while the risks of using new
technology are often unknown and may involve great societal upheaval in
learning to adapt to them. Yes, wood smoke may cause lung cancer, but note
that recent studies in Great Britain show that the incidence of prostate
cancer in men who work in atomic power plants is many times that of the
general population. To delay introducing technology in order to assure that
greater risks are not incurred than are currently borne by the population
seems justifiable. Yes delay may cause someone's death, but the
introduction may cause even more deaths and disruption in the long-run.
The solution is to develop ways to assess the risks accurately (so that
intelligent, well-informed decision-making is possible) and to develop ways
to reduce the risk as much as possible. Returning to the topic of computer
risk, citizens and government agencies need to be able to make informed
decisions about such things as the safety of fly-by-wire computer-controlled
commercial aircraft or between computer-controlled Air Traffic Control with
human-assistance vs. human-controlled Air Traffic Control with computer
assistance. To do this, we need to be able to assess the risks and to
accurately state what computers can and cannot do.
Forums like this one help to disseminate important information and promote
the exchange of ideas, But we also need to start new initiatives in computer
science research and practice. I have been writing and lecturing about this
for some time. For example,
1) we need to stop considering software reliability as a matter of
counting bugs. If we could eliminate all bugs, this would work. But
since we cannot at this time, we need to differentiate between the
consequences of "software failures."
2) Once you start to consider consequences of failures, then it is possible
to develop techniques which will assess risk.
3) Considering consequences may affect more aspects of software than just
assessment. Some known techniques, such as formal verification and
on-line monitoring, which are not practical to detect all faults may be
applied in a cost-effective manner to subsets of faults. Decisions may
be able to be made about the use of competing methodologies in terms of
the classes of faults that they are able to detect, remove, or tolerate.
But most important, by stating the "software problem" in a different way
(in terms of consequences), it may be possible to discover new approaches
to it. My students and I have been working on some of these. Most
software methodologies involve a "forward" approach which attempts to
locate, remove, or tolerate all software faults. An alternative is to
take a backward approach which considers the most serious failures and
attempts to determine if and how they could occur and to protect the
software from taking these actions.
If using some of these techniques (or despite their use), it is determined
that the software would be more risky than conventional systems or is above
a minimum level of acceptable risk, then we can present decision makers with
these facts and force them to consider them in the decision-making process.
Just citing horror stories or past mistakes is not enough. We need ways of
assessing the risk of our systems (which may involve historical data
presented in a statistically proper manner) and ways to decrease that risk
as much as possible. Then society can make intelligent decisions about
which systems should and should not be built for reasons of acceptable or
unacceptable risk.
------------------------------
Date: 8 Sep 1985 12:00-EST
From: Nicholas.Spies@CMU-CS-H.ARPA
Subject: Risks of omissions
To: JMC@SU-AI
Cc: risks@sri-csl
The question of responsibilities for non-use of computers are largely
meaningless in terms of law unless the dangers of non-use were known to
substantially increase the probability of greater harm. In the case of your
three short examples:
(1) If the ACLU had acted in good faith in seeking to limit sharing of
police information and a court had looked favorably on their argument after
weighing the possible risks, then the court is responsible because only the
judge had the ability to decide between two courses of action. To make the
ACLU responsible would be to deny it and its point of view access to due
legal process. To make it necessary for the ACLU to anticipate the court's
response to its bringing suit would have the same chilling effect on our
legal system.
(2) The same argument applies to the Sierra Club and US 101. If US 101 had
been built and then some people were killed, one could as easily conclude
that the Sierra Club (or anyone else) might be sued for NOT obstructing the
highway!
(3) The "Split Wood not Atoms" poster-vendor might be sued if it could be
conclusively proven that he was a knowing party to a conspiracy to give
people lung cancer. But we might assume that his motivation was actually to
prevent a devastating nuclear accident that might have given 10,000 people
lung cancer...
Again, a risks-of-computers organization can only present its case to court
and people and, so long as no malfeasance is involved, cannot be held
responsible for its failure to predict future consequences. There are far
more important "unsymmetric" relationships than that of the press vs. the
legal system that pertain to issues of responsibility, namely, that of past
vs. future and known vs. unknown. I feel that you are correct in pointing
out how computer people would do well to apply their expertise to solving
problems of society. In this case the moral imperitives are quite clear.
------------------------------
Date: Sun, 8 Sep 85 15:51:44 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
Subject: Risks of omissions (not using some technology)
To: JMC@SU-AI.ARPA
cc: RISKS-FORUM@MIT-MC.ARPA, risks@SRI-CSL.ARPA
The problem with a forum on the risks of technology is that
while the risks of not using some technology, e.g. computers, are
real, it takes imagination to think of them....
You raise an interesting point that deserves more discussion.
However, as one who is concerned that the major problem arises from an
uncritical acceptance of technology, I strongly disagree with your
suggestion that the scales are stacked AGAINST those who are
"pro-technology". The reason that anyone adopts any given technology
is that it provides benefits that he can see; the problem is getting
those individuals to see that there are costs as well. In other
words, the bias in the system is towards acceptance of technology, not
rejection of it. It is this general bias that "risks" people are
trying to correct.
...Is a risk-of-computers
organization that successfully sues to delay a use of computers either
MORALLY or LEGALLY LIABLE if the delay causes someone's death? Is there
any moral or legal requirement that such an organization prove that they
have formally investigated whether their lawsuit will result in killing
people? As the above examples indicate, the present legal situation
and the present publicity situation are entirely unsymmetric.
There are such precedents; organizations can be held liable for using
technology that that is not as up to date as is "generally
applicable". On the more general point, it is much harder to
establish liability as the result of someone's inaction as compared to
the result of someone's action; this does happen, but it is harder to
prove.
The harm caused by tape-to-tape batch processing as opposed to on-line
systems.
I like this example; let's have more discussion of it. There was a
time when on-line systems were totally unreliable, but I think that
time has past.
Shouldn't computer professionals
who pretend to social responsibility take an interest in an
area where their knowledge might actually be relevant?
This is a cheap shot unworthy of pioneers in computer science. More
than anyone else, computer professionals are the ones who are in the
best position to assess the limits as well as the promises of
technology. You once said that the responsibility of the scientist is
to take his science whereever it may lead. I agreed with you then,
and I agree with that now. But science is part of a social and
cultural context, and cannot be separated as cleanly as one might
imagine. If it is proper for the developers of science and technology
to propose new applications of their work (because they see these
potential applications as beneficial to society), it is also
appropriate for them to suggest possible consequences of their use as
well.
------------------------------
Date: Sun, 8 Sep 85 09:06:10 pdt
From: vax-populi!dparnas@nrl-css.arpa (Dave Parnas)
To: Neumann@SRI-CSLA.ARPA
Subject: Risks of omissions; Weizenbaum's message
ReSent-To: risks@SRI-CSLA.ARPA
1. McCarthy's contribution can be summarized simply, "Life is
full of tough decisions about when to use technology; we have to
consider both sides." Those who have been concerned with the risks
of computer technology have been saying, "There are risks to using
computer technology; we have to consider both sides". I sense
agreement on the obvious conclusion.
2. I can disagree only with one aspect of Weizenbaum's contribution.
He says that he would be against SDI even if it would work, but his arguments
mainly show even more reasons why it won't "make nucelar weapons impotent
and obsolete." It is probably useless to argue about how we would feel
about the system if it would work, but I feel the decision would be much
harder to make than it is now.
While I would prefer not to waste technological resources on such a thing,
I would see some truth in the argument that the non-technological solutions
also have a clear risk of failure.
Dave
------------------------------
Date: 08 Sep 85 1108 PDT
From: John McCarthy <JMC@SU-AI.ARPA>
Subject: Hot rodding you AT and the weather
To: risks@SRI-CSL.ARPA
Assuming, contrary to fact, that putting a faster clock
in your AT would cause it to catch fire, the RISKS contributors are
quite wrong about who would be sued. According to the new legal
doctrine of bursae profundae, it isn't the poor BBOARD operator
that would have to pay but rich IBM. It wouldn't take much of a lawyer
to figure out that IBM should have anticipated that someone might
do this and warned against it or even somehow made it impossible.
Changing the subject, consider the effect of the court decision that
NOAA was liable for not fixing the buoy. Up to now weather predictions
have been offered as a non-guaranteed service with the user taking
responsibility for the extent to which he relies on it. The court
has said that this is no longer possible. Any institution with
"deep pockets" cannot safely offer information on a user responsibility
basis. What if Stanford University has negligently failed to
replace a stolen book from its medical library, and someone dies
who would have been saved had his doctor found the book? Stanford's
lawyers should advise Stanford to deny access to its medical library
to practicing physicians.
------------------------------
Date: Sun, 8 Sep 85 11:23:16 EDT
From: Brint Cooper <abc@BRL.ARPA>
To: RISKS@SRI-CSL.ARPA
cc: BRANDIN@SRI-AI.ARPA
Subject: Re: Good Risks and Bad Risks
Another example of "good news/bad news" is the use of
computerized axial tomography (CAT scans) as a substitute for
exploratory surgery in the head and body.
Advantages: elimination of much surgical risk;
negative diagnoses (disease NOT present) without surgery
much lower cost
Disadvantages: because of the advantages, CAT scans may be over-used;
increased exposure to X-rays which, itself, can be
disease-enhancing
Brint
------------------------------
Date: Sun, 8 Sep 85 15:58:27 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
Subject: SDI reliability
To: mooremj@EGLIN-VAX.ARPA
cc: RISKS-FORUM@MIT-MC.ARPA, risks@SRI-CSL.ARPA
My primary complaint about your otherwise interesting table is that it
assumes independent failure modes. I think it is much more likely
that the effects of coupled failures are larger. In particular, given
the failure of one platform, it is more likely that more than one will
fail.
------------------------------
Date: Sun, 8 Sep 85 16:02:40 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
Subject: Viruses, Trojan horses, and worms
To: Neumann@SRI-CSL.ARPA
cc: LIN@MIT-MC.ARPA, RISKS-FORUM@MIT-MC.ARPA, RISKS@SRI-CSL.ARPA,
SIDNEY.G.HAPGOOD@MIT-OZ
..... The example of squirreled
control characters and escape characters that do not print but cause
all sorts of wonderful actions was popular several years ago, and
provides a very simple example of how a message can have horrible
side-effects when it is read.
But if *I* have designed my operating system to display only what it
receives, how is this possible?
------------------------------
Date: Sun 8 Sep 85 13:35:05-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Re: Viruses, Trojan horses, and worms
To: LIN@MIT-MC.ARPA
The example of squirreled non-printing characters is of course just
one example; that one was relatively easy to fix once it was recognized.
But until you have discovered a flaw, you are vulnerable. And you never
know how many flaws remain undiscovered.
Sure, *you* may be smart, but large operating systems generally have many
security flaws. *You* probably aren't smart enough to design and build a
system that has none. (In fact, your solution is not quite good enough
by itself -- without some other assumptions on the rest of your system.)
Peter
[By the way, let me add before someone comments, a message that causes
grief when read would be a Trojan horse. A message that propagates itself
-- as in the case of the ARPANET collapse on 27 Oct 1980 -- would be
a virus. A BBOARD message that is innocently moved to another system
by third parties for others to get clobbered by has aspects of both --
a virus-propagated Trojan horse . PGN]
------------------------------
Date: Sun, 8 Sep 85 16:40:44 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
Subject: Viruses, Trojan horses, and worms
To: Neumann@SRI-CSL.ARPA
cc: LIN@MIT-MC.ARPA
In-reply-to: Msg of Sun 8 Sep 85 13:35:05-PDT from Peter G. Neumann <Neumann at SRI-CSLA.ARPA>
Sure, *you* may be smart, but large operating systems generally have many
security flaws. *You* probably aren't smart enough to design and build a
system that has none. (In fact, your solution is not quite good enough
by itself -- without some other assumptions on the rest of your system.)
I certainly recognize that operating systems have security flaws in
them, having been an OS hacker myself at one time. But for the
problem of messages (as opposed to programs) doing bad things to my
system, I guess I never figured out a way of doing that.
My naive model is that I have a special program that intercepts the
raw bit stream that comes in from my communications port. It then
translates this into ASCII, and then prints it on my screen.
If this is all that my program does, I can't see what harm can be
done.
Now, if my program writes the message to disk, then I can see
potential problems. So I simply count the characters that are sent to
me over the line, and save exactly that many characters on disk.
What am I missing?
------------------------------
Date: Sun 8 Sep 85 14:47:21-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Re: Viruses, Trojan horses, and worms
To: LIN@MIT-MC.ARPA
Herb, Indeed your model is a bit naive, in that you are looking at the
problem much to narrowly, and assuming that *everything* *else* works fine.
Suppose that your special program would work as you wish in intercepting the
raw bit stream. Suppose, however, that there is an operating system flaw
that lets me change your special program to do what I wish! (There are many
examples of how this might happen.) Now your program can be effectively
bypassed. The point is NOT whether you can seal off one hole, but rather
that you are dealing with the tip of an iceberg and there may be titanic
holes you don't even know about. Besides, as I said earlier, the message
squirreling is only one example -- and hopefully completely cured. So I
hope you don't reply that you could use seals to guarantee that your program
is unchanged. That would still miss the broader point. PGN
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂09-Sep-85 1257 YAMARONE@SU-CSLI.ARPA ONE EXTRA SANDWICH:TURKEY/LT.RYE
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 9 Sep 85 12:57:24 PDT
Date: Mon 9 Sep 85 12:52:06-PDT
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: ONE EXTRA SANDWICH:TURKEY/LT.RYE
To: folks@SU-CSLI.ARPA
there happens to be one extra sandwich available at the desk:
turkey on light rye: 2.50
ignore this message if you receive it later than 1:15.
Thanks, the Ventura Sandwich Corp.
-------
∂09-Sep-85 1337 SUSI@SU-CSLI.ARPA
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 9 Sep 85 13:37:04 PDT
Date: Mon 9 Sep 85 13:28:04-PDT
From: Susi Parker <SUSI@SU-CSLI.ARPA>
To: folks@SU-CSLI.ARPA
THE turkey on light rye is still available and edible...until further notice
-------
∂09-Sep-85 1417 CAROL@SU-CSLI.ARPA DANDELION ASSISTANCE
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 9 Sep 85 14:17:15 PDT
Date: Mon 9 Sep 85 14:10:19-PDT
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: DANDELION ASSISTANCE
To: FOLKS@SU-CSLI.ARPA
Hi. I'm Carol Kiparsky. As promised in the long message summarizing the first Dandelion Users' Group meeting, I am here to help people at CSLI use the dandelions.
First of all, I am assembling a package of documentation concerning such areas as: the basics of the Interlisp-D world (windows, mouse, etc.), the editing system, useful packages, troubleshooting, and using CHAT to simulate a terminal so you can, for instance, use the mail system.
Secondly, I am on hand to give tutorials to new users or answer questions that arise while you use the machines.
Third, I will attempt to keep you informed of relevant developments from PARC.
By the end of the month I hope to have the package of documentation ready. The material will be available in hardcopy, and also as files on the directory:
{csli}<dandelion.doc>
which is open to all to read and print out. At this point it contains material on the TEdit editing system. Browse this directory, and if you don't see what you want, contact me. Hopefully I can find it for you.
Address questions and requests for documentation, appointments, or other assistance to Carol@csli, or call me at 497-0939, or drop in weekdays at F2.
-------
∂09-Sep-85 1517 @SU-CSLI.ARPA:GEORGEFF@SRI-AI.ARPA PLANLUNCH resumes next week
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 9 Sep 85 15:17:12 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 9 Sep 85 15:09:51-PDT
Date: Mon 9 Sep 85 09:08:11-PDT
From: Michael Georgeff <georgeff@SRI-AI.ARPA>
Subject: PLANLUNCH resumes next week
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, rsimmons@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
vanLehn@XEROX.ARPA, araya@XEROX.ARPA, frayman@XEROX.ARPA,
suchman@XEROX.ARPA, weld@XEROX.ARPA, mittal@XEROX.ARPA, dekleer@XEROX.ARPA
The PLANLUNCH seminars will resume next Monday (September 16).
The speaker next week will be Dave Wilkins.
Mike.
-------
∂09-Sep-85 2134 NEUMANN@SRI-CSLA.ARPA RISKS-1.9, 09 Sep 85
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 9 Sep 85 21:34:04 PDT
Date: Mon 9 Sep 85 20:40:51-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.9, 09 Sep 85
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS: ;
RISKS-FORUM Digest Monday, 9 Sep 1985 Volume 1 : Issue 9
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
McCarthy, Weizenbaum on SDI (Douglas Schuler)
Why I'm against even a reliable SDI (Jeffrey Mogul)
Risk Assessment and Risk Management (Edward V. Berard)
Risks in displaying a file containing control characters (Keith F. Lynch)
[*** Apologies to those of you who have been suffering from INDIGESTIFICATION.
The blank line before the following 70 hyphens makes the difference, and your
undigestification programs should now work on RISKS! PGN ***]
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Mon, 9 Sep 85 09:34:15 pdt
From: bcsaic!douglas@uw-june (douglas schuler)
To: RISKS@SRI-CSL
Subject: McCarthy, Weizenbaum on SDI
Joseph Weizenbaum states that he would be against SDI "even if it worked."
I agree. The premise that "IF the SDI could work, then we must have it (at
any price)" is naive. It seems that many people are willing to accept that
premise hoping that it will anchor the discussion in the technical area.
One factor which is rarely addressed is that of intermediate systems which
the SDI will spawn. There is a tendency to think of the SDI system as being
one big system that one day appears overhead as a whole, integrated system.
I have little doubt that the SDI plan includes many deliverables along the
way. These intermediate systems will both be arguably non-defensive and
pose a large problem for integration. I.e., the system must not only be
trustworthy when "fully deployed" but at a multitude of intermediate steps.
Thus risks will exist in advance of the full delivery (if there ever is to
be one).
Another factor is the so-called defensiveness of the system. If two people
are armed with guns and one suddenly dons a bullet proof vest this act will
be perceived as an offensive act.
Pro-SDI people almost always accuse SDI critics of being politically
motivated. Given the immense (and possibly impossible) technical task of
getting the system to work, and the guarenteed proliferation of offensive
weapons (designed to penetrate the system), it is very, very difficult for
me to believe that the pro SDI folk are not motivated primarily from
political (and economic!!) grounds.
- Doug Schuler
------------------------------
Date: Mon 9 Sep 85 16:40:02-PDT
From: Jeffrey Mogul <MOGUL@SU-SCORE.ARPA>
Subject: Why I'm against even a reliable SDI
To: risks@SRI-CSL.ARPA
To quote from RISKS Vol 1 #8:
2. I can disagree only with one aspect of Weizenbaum's contribution.
He says that he would be against SDI even if it would work, but his
arguments mainly show even more reasons why it won't "make nucelar weapons
impotent and obsolete." It is probably useless to argue about how we
would feel about the system if it would work, but I feel the decision
would be much harder to make than it is now. [Dave Parnas]
I think this touches on the crux of the matter: what problem is SDI meant to
solve? If we could guarantee that SDI would not only "make nuclear weapons
impotent and obsolete", but would in fact reduce the risks associated with
war (not necessarily the same thing) then I would not be against SDI.
However, I argue (and I suspect this is Weizenbaum's point, too) that an SDI
that worked according to the current specification would actually increase
risks, even though the system performed "flawlessly".
This is not the place to discuss the strategic implications of SDI, but I
think it's important to realize that there are those of us who believe both
that SDI is not likely to meet its current specification, nor that it would
be a good idea even if it did.
[I] would see some truth in the argument that the non-technological
solutions also have a clear risk of failure. [Parnas]
I am afraid that there is no failure-proof solution, technological or not,
to the problem of "war". John McCarthy is right that we must compare
the risks of the technological solution (e.g., SDI) to its non-use. My
fear is that, in this case, the problem is not that the use of technology
might fail to solve the problem, but that it might actually make things
worse.
------------------------------
Date: Mon 9 Sep 85 08:16:07-PDT
From: Edward V. Berard <EBERARD@USC-ECLB.ARPA>
Subject: Risk Assessment and Risk Management
To: risks@SRI-CSL.ARPA
There has been some discussion of comparing alternative risks on the
RISKS mailing list lately. For example, what is the risk associated
with the introduction of a new technology versus not introducing the
technology? Risk assessment and risk management need not be
"guesstimates" nor "a number picked out of the air."
The insurance industry has had to assess and manage risks for years.
In fact, they have made quite a science out of these two areas. I
would recommend that those who wish to find out more about risk
management and risk assessment read:
RISK MANAGEMENT AND INSURANCE, Fourth Edition, by C. Arthur
Williams, Jr. and Richard M. Heins, McGraw-Hill, 1981.
Don't let the title put you off. Virtually the entire book is
dedicated to risk management, with only a few pages on insurance. You
will also find that there are entire professional societies dedicated
to managing and assessing risk, e.g., the American Risk and Insurance
Association and the Risk and Insurance Management Society.
-- Ed Berard
EBerard at ECLB
(301) 251 - 1626
------------------------------
Date: Mon, 9 Sep 85 00:26:04 EDT
From: Keith F. Lynch <KFL@MIT-MC.ARPA>
Subject: Risks in displaying a file containing control characters
To: LIN@MIT-MC.ARPA
cc: Risks@SRI-CSL.ARPA, Security@RED.RUTGERS.EDU
Date: Sun, 8 Sep 85 16:40:44 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
My naive model is that I have a special program that intercepts the
raw bit stream that comes in from my communications port. It then
translates this into ASCII, and then prints it on my screen.
If this is all that my program does, I can't see what harm can be done.
Several kinds of terminals are programmable from the host, in that
certain escape sequences can be sent to them to get them to perform
actions such as defining the terminal's function keys.
If a user inserts the appropriate escape sequences in a mail message
to his system manager, or into a file which will be displayed by the
manager, when the manager reads that mail message it will reprogram
a function key on the manager's terminal, which the manager may have
programmed to do some common harmless function, to instead do some
other command such as give the user unauthorized privileges.
This is a fairly well known bug, and many mail systems are now
protected against it, in that they will not transmit any control
characters or escape sequences to the terminal.
The moral is that there are many subtle ways to break security,
and even things that seem to be quite safe may not really be.
...Keith
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂09-Sep-85 2347 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #14
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Sep 85 23:47:36 PDT
Date: 9 Sep 85 2335-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #14
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Tuesday, 10 Sep 1985 Volume 1 : Issue 14
Today's Topics:
Recent books and the symbolic computing discussion
RIACS job openings
Programming language theory seminar (MIT)
IJPP: new journal on parallel programming
----------------------------------------------------------------------
From: eugene@AMES-NAS.ARPA (Eugene Miya)
Date: 3 Sep 1985 1644-PDT (Tuesday)
Subject: Recent books and the symbolic computing discussion
The following titles have just appeared at Computer Literacy Book store.
I have not seen any of them at Stanford or Staceys yet:
%A John A. Sharp
%T Data Flow Computing
%I John Wiley & Sons, Inc.
%D 1985
%X Appears to have a slight English bias. Very little about SISAL,
some VAL.
%A William W. Wadge
%A Edward A. Ashcroft
%T Lucid, the Data Flow Programming Language
%I Academic Press
%D 1985
%A W. Daniel Hillis
%T The Connection Machine
%I MIT Press
%D 1985
%X A collection of papers on the ideals of this architecture.
%A J. L. Potter, ed.
%T The Massively Parallel Processor
%I MIT Press
%C Cambridge, MA
%D 1985
Sorry, they are in refer format. I don't have Scribe.
I think the discussion on the distinction between numeric and
symbolic computing was way too one sided. I was not
a very good devil's advocate in the beginning. I have been
following a discussion on Scientific Programming Languages in
the net.lang newsgroup [much more lively, one chap really defended
using Ada]. The supporters of LISP were alive and a sub group
has spun off discussing why LISP isn't used more in scientific
environments. It has not occurred to them that a lot of
engineers and scientists prefer "X = 1 + 2" to "(ADD 1 2)" semantics
aside. I fear we have to get FORTRAN classes out of the physics
departments or else the physicists are not going to see the
advantages of tools like macsyma.
--eugene miya
NASA Ames Research Center
------------------------------
[Forwarded by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
From: Nancy Blachman <nancy@RIACS.ARPA>
Date: 26 Aug 1985 1405-PDT (Monday)
To: arpanet-bboards@mit-mc.ARPA
Subject: Openings at the forefront of Computer Science
We, the Research Institute for Advanced Computer Science (RIACS), are
looking for a systems programmer to provide support for computer science
research in distributed computing, concurrent processing and programming,
among other things. We are a private non-profit contractor to NASA Ames
Research Center. We are committed to UNIX (primarily BSD) shop and an
Internet site (riacs.ARPA).
We have the following equipment:
Sequent Balance 8000 (12 processors, 16MB main memory, 1.5GB disk,
32 ttys, 16 users, 4.2BSD),
VAX 11/730 (3MB main memory, 110MB disk, 4 dialin/out, 0 users
[uucp/usenet/internet gateway], 4.2BSD),
Ridge 32C (4MB main memory, 370MB disk, SysV & 4.2BSD layered over
ROS 3.3, 0 users [compute server]),
SGI IRIS 1500 Color Graphics Workstation (68k, geometry engine,
SysV with 4.2 enhancements and TCP/IP),
Intel iPSC hypercube (32 nodes, delivery 8/19/85),
BBN and Forward Technology bitgraph terminals,
as well as plans and a budget for:
color graphics system (unspecified),
workstations (unspecified).
All machines are networked together (TCP), and all have full access to
MILNet, ARPANet, and UUCP.
The systems programmer would work on problems such as:
Simulators for new memory architectures that will be used as
components of autonomous robotic systems in the Space Station
Project.
Creation of high performance workstations for use in the Space
Sciences and Human Factors branches.
Support for multimedia and private network telecommunications
as part of scientific collaboration.
Computational fluid dynamics (CFD) research, using an IRIS
workstation as tool to develop flow simulations and also as
front end for a Cray-2 and other supercomputers in the Numerical
Aerodynamic Simulation (NAS) project.
Currently there are 19 people at RIACS, including five summer students and
10 research scientists. Our environment is university-like, however, our
salaries are on par with industry. We are located at the NASA Ames Research
Center in Mountain View, California. (We are an EOE employer.)
We are looking for someone with a solid UNIX systems programming
background. If you are interested in the position, you have at least two
years experience with UNIX, and you are a U.S. citizen or you hold a
permanent resident visa, then to apply for the position, send a cover
letter, resume, and names of three references to:
Peter J. Denning, Director
RIACS
Mail Stop 230-5
NASA Ames Research Center
Moffett Field, CA 94035
or
nancy@riacs.ARPA
If you simply want more information contact me directly.
Nancy Blachman
nancy@riacs.ARPA
415-694-6144
------------------------------
[Forwarded by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
Date: 09/08/85 17:59:32
From: MEYER at MIT-XX.ARPA
Re: Programmng language theory seminar
To: *bboard@MIT-XX
Subject: Programming language theory seminar
cc: types@mc, toc@mc
SEMINAR IN PROGRAMMING LANGUAGE THEORY
TYPES; CONCURRENCY SEMANTICS; ETC.
ORGANIZING CALL
Reading seminar for presentation of recent papers. Main foci on
generalized types in programming and concurrency semantics. Tentative
time Thursdays at 3:00; first official meeting Thursday, Sept.19 in
3rd floor conference room. If interested, send mail to MEYER@MC
indicating your schedule and papers you'd like to present or see
presented. Credit can be arranged.
Papers currently proposed are
- Semantics of concurrent programs based on observed computational
behavior [Pnueli 85], [Hennessy 85], [Larsen 85], [Stirling 85],
[Graf, Sifakis 85],
- Theory of representation independence of abstract data types
[Mitchell, Meyer 85], [Donahue, Demers 85], [Reynolds 83], [Plotkin 80],
[Statman 85], [Fokkinga 81],
- Simple types: semantics [Coppo 85], [Breazu-Tannen, Meyer 85],
continuations [Meyer, Wand 85],
- type checking [Mishra, Reddy 85] and extensible type system
facilities [Lucassen, Gifford 85].
REFERENCES
Breazu-Tannen, V. and A.R. Meyer. Lambda calculus with constrained types
(Extended abstract). In Logics of Programs, Lect. Notes in Comp. Sci. 193,
Parikh, Rohit, Ed., Springer-Verlag, 1985, 23-40.
Coppo, M. A completeness theorem for recursively defined types. In Int'l
Conf. Automata, Languages and Programming, Lect. Notes in Comp. Sci. 194,
Brauer, Wilfried, Ed., Springer-Verlag, 1985, 120-129.
Donahue, James and Alan Demers. Data types are values. ACM Trans. on
Programming Lang. and Systems 7 (1985), 426-445.
Fokkinga, Maarten M. On the notion of strong typing. In
Algorithmic Languages, DeBakker, J. and van Vliet, Eds., IFIP, North-Holland,
1981, 305-320.
Graf, S. and J. Sifakis. From synchronisation tree logic to acceptance. In
Logics of Programs, Lect. Notes in Comp. Sci. 193, Parikh, Rohit, Ed.,
Springer-Verlag, 1985, 128-142.
Hennessy, M. An algebraic theory of fair asynchronous communicating processes.
In Int'l Conf. Automata, Languages and Programming, Lect. Notes in Comp. Sci.
194, Brauer, Wilfried, Ed., Springer-Verlag, 1985, 260-269.
Larsen, K.G. A concept dependent equivalence between processes. In Int'l
Conf. Automata, Languages and Programming, Lect. Notes in Comp. Sci. 194,
Brauer, Wilfried, Ed., Springer-Verlag, 1985, 373-382.
Lucassen, John M. and David K. Gifford. A strongly typed language with an
extensible type system. 1985, MIT, extended abstract submitted to POPL 86.
Meyer, A.R. and M. Wand. Continuation semantics in typed lambda-calculi
(Summary). In Logics of Programs, Lect. Notes in Comp. Sci. 193, Parikh,
Rohit, Ed., Springer-Verlag, 1985, 219-224.
Mishra, Prateek and Uday S. Reddy. Declaration-free type checking. In 12th
ACM Conf. Principles of Programming Languages, 1985, 7-21.
Mitchell, J.C. and A.R. Meyer. Second-order logical relations (Extended
Abstract). In Logics of Programs, Lect. Notes in Comp. Sci. 193, Parikh,
Rohit, Ed., Springer-Verlag, 1985, 225-236.
Plotkin, Gordon D. Lambda-definability in the full type hierarchy. In To H.B.
Curry: Essays on Combinatory Logic, Lambda Calculus and Formalism, Seldin, J.P.
and J.R. Hindley, Eds., Academic Press, 1980, 363-373.
Pnueli, A. Linear and branching structures in the semantics and logics of
reactive systems. In Int'l Conf. Automata, Languages and Programming, Lect.
Notes in Comp. Sci. 194, Brauer, Wilfried, Ed., Springer-Verlag, 1985, 15-32.
Reynolds, John C. Types, Abstraction, and Parametric Polymorphism. In
Information Processing 83, R.E.A. Mason, Ed., 1983, 513-523. North-Holland
Publishers.
Statman, R. Logical relations in the typed lambda-calculus. 1985, To appear,
Information and Control.
Stirling, C. A complete compositional modal proof system for a subset of CCS.
In Int'l Conf. Automata, Languages and Programming, Lect. Notes in Comp. Sci.
194, Brauer, Wilfried, Ed., Springer-Verlag, 1985, 475-486.
------------------------------
[Forwarded by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
Date: Sun 1 Sep 85 23:29:07-PDT
From: Gary Lindstrom <Lindstrom at UTAH-20.ARPA>
Sender: udi at wisc-rsch.arpa
To: potential-authors:; at UTAH-20.ARPA
Re: IJPP: new journal on parallel programming
The following is an announcement of a new journal. Contributions are now
actively being solicited, as explained below. Please post this message
on local bulletin boards (hard and soft!).
Thanks,
--Gary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
INTERNATIONAL JOURNAL OF PARALLEL PROGRAMMING
Editor-in-Chief:
Gary Lindstrom
Department of Computer Science
University of Utah
Salt Lake City, Utah 84112
(801) 581-5586
Lindstrom@Utah-20.ARPA
Published by:
Plenum Publishing Corporation
233 Spring Street
New York, NY 10013
(212) 620-8000
Statement of Purpose:
Parallel computer systems are characterized by the coexistence of
multiple coordinated activities. Physically, such systems range from networked
independent computers to high performance single-chip processors.
While parallelism has long been a physical reality in computer systems,
its impact on programming practice has in the past generally been felt only by
specialists in systems programming. A new trend, however, is clearly emerging:
that of parallelism as a vital aspect of programming at all levels.
The reasons for this trend are several, including the growing purview
of higher level languages, more elegant computing models relieved of sequential
computing ideology, and exciting new ideas in computer architecture motivated
by the advent of VLSI.
The International Journal of Parallel Programming (IJPP) will offer a
window on these developments from a programmer's perspective. Thus while no
pertinent aspect of parallel computing systems will be excluded a priori,
each contribution will observe the common theme of illuminating in some manner
the programming challenges presented by parallel computing systems.
Scope:
Sample areas to be addressed in IJPP include (with a short suggestive
list of appropriate subareas mentioned in each case):
* linguistic foundations (semantic formulations, abstract machine
models)
* conceptual frameworks for parallel computation (actors, guardians,
synchronized tasks, functional and logic programming)
* high-level languages for parallel programming (new formulations and
extensions to existing languages)
* evaluation methods (dataflow, reduction, eager vs. lazy evaluation)
* implementation techniques (compilation, emulation, storage and
name space management)
* programming support systems (run-time libraries, debuggers,
performance instruments)
* pragmatic considerations (task granularity, load distribution and
scheduling, error detection and recovery)
* architectural characteristics (synchronous vs. asynchronous control,
shared vs. partitioned memory, physical locality, reliability)
* software engineering aspects (specification and design
methodologies, rapid prototyping, migration of sequential code,
verification and testing)
* advances in parallel algorithms (prototypical problems, relationships
to particular languages and evaluation methods)
* performance studies (fundamental and empirical)
* application studies (artificial intelligence, simulation, databases,
numeric computation)
In addition to full length refereed contributions, IJPP will offer a
department entitled "Nonpareil" (meaning, in French, both "nonparallel" and
"matchless"). Under this rubric will appear short contributions of a lighter
nature, including anecdotes, tongue-in-cheek commentary, and other entertaining
insights into the travails of parallel programming.
Editorial Board:
A distinguished Editorial Board comprising approximately 20 experts in
the areas cited above is now being formed.
Commencement of the Journal:
The first issue of IJPP will appear on or about July 1, 1986. Six
issues of approximately 90 pp. each will be issued per year.
IJPP will be the successor to the International Journal of Computer and
Information Sciences, concluding fourteen volumes published under the
editorship of Julius T. Tou. The first issue of IJPP will thus be designated
volume 15, number 1.
Call for Papers:
Manuscripts for possible publication in IJPP should be sent to the
Editor-in-Chief. Contributions must be in English, and previously unpublished.
Four single-sided copies are requested.
To ensure eligibility for inclusion in the inaugural issue, manuscripts
should be received by October 15, 1985.
Electronic mail will be used for correspondence with contributors
whenever feasible, and network addresses should be prominently indicated on
all submissions and inquiries.
------------------------------
End of PARSYM Digest
********************
∂10-Sep-85 1014 RICE@SUMEX-AIM.ARPA Tomorrow's Meeting.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 10 Sep 85 10:14:11 PDT
Date: Tue 10 Sep 85 10:14:34-PDT
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: Tomorrow's Meeting.
To: aap@SUMEX-AIM.ARPA
Message-ID: <12142174130.25.RICE@SUMEX-AIM.ARPA>
Ok, This is your last warning.
9 am. Wed Sept 11
Dr Shimon Cohen (Schlumberger P.A. res.)
will describe language development work that
he is doing as part of the Faim project.
Rice
-------
∂10-Sep-85 1402 RICHARDSON@SU-SCORE.ARPA Sr. Faculty Meeting
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 10 Sep 85 14:02:25 PDT
Date: Tue 10 Sep 85 13:58:39-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Sr. Faculty Meeting
To: tenured@SU-SCORE.ARPA
Message-ID: <12142214922.31.RICHARDSON@SU-SCORE.ARPA>
There will be a sr. faculty meeting on September 24, 1985 following the
general faculty meeting scheduled at 2:30 in Conference Room 146 of
Margaret Jacks Hall. Should you have any agenda items that you would like
to be included, please indicate to me.
Thanks,
Anne Richardson
-------
∂10-Sep-85 2130 ullman@diablo weird message
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 10 Sep 85 21:30:29 PDT
Date: Tue, 10 Sep 85 21:27:13 pdt
From: Jeff Ullman <ullman@diablo>
Subject: weird message
To: nail@diablo
There was a message from outer space yesterday, announcing last week's
meeting. This week's meeting will be at our usual time, 11AM
wednesday in 301. Jeff Naughton is the speaker.
∂11-Sep-85 1239 BETSY@SU-CSLI.ARPA CSLI Activities in 1985-86
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 12:39:27 PDT
Date: Wed 11 Sep 85 12:30:26-PDT
From: Betsy Macken <BETSY@SU-CSLI.ARPA>
Subject: CSLI Activities in 1985-86
To: folks@SU-CSLI.ARPA
The following is information about our plans for the structure of CSLI
activities in 1985-86:
As you know, we have organized the CSLI budget and our remaining SL
funds around the projects described in your proposals. We stated in
the second year report that these projects are the ones CSLI is
committed to for the next three or four years. We'd like you to
commit to regular meetings for your project, and we want to organize
our seminars and colloquia around them as well.
Project Meetings
To facilitate regular meetings, we are trying to make the Ventura site
a more attractive place to hold them, particularly during the hours
around lunch time. We have plans to improve and expand our common
areas and our lunch service. Regular transportation from SRI and PARC
could also be arranged if this would be helpful. We'd like you to
consider saving the hours between 11 and 2 for project meetings; this
would give you 14 one-hour slots (excluding the TINlunch slot) per
week to choose from, and we thought that by everyone thinking of these
times as CSLI times, it might be easier to arrange meetings and also
to find people available for informal meetings. In addition, it would
eliminate the need for people to go back and forth between sites two
or three times in a day.
TINLunch
TINLunch will have the same format as in previous years. Chris
Menzel and Mats Rooth will be our leaders this year.
Thursday Seminars
Besides individual presentations from the postdocs, we'd like each
project to present its goals and progress in at least one seminar
meeting during the coming year. I have attached a tentative list of
dates for projects and postdocs to give seminars. You are free to
trade with each other if the dates are not appropriate, but you do
need to let me know of whatever trades you make so that we always have
an updated list.
Thursday Colloquia
We'd like to make CSLI's colloquium series a major part of our outreach
program where each meeting is of exceptionally high interest to the
majority of CSLI researchers and, as much as possible, to the wider
academic community. At the same time, we'd like to have fewer and less
regular meetings to allow more time and flexibility for your project
meetings.
To accomplish this we decided to:
1) Have three colloquia meetings each quarter
2) Ask projects to be responsible for, or share the
the responsibility for, one meeting
3) Be flexible about the meeting times and places; that
is, meetings can be held in the evenings and in lecture
rooms which are larger than G-19 whenever necessary
4) Provide up to $1000 per meeting from general funds
for guest speakers
I have tentatively partitioned the academic year into 9, 2- to 3-week
periods and assigned one or more project to each period. I've asked
the projects to be responsible for one colloquium meeting within their
assigned period of time or for making alternative arrangements by
combining forces or trading with other projects.
Exceptions
If you have ideas for additional seminars or colloquia that don't seem
to fit in these lists, please let me know and I'll work out a way to
schedule them. We have already had some requests, and we don't want
to turn down interesting events.
- Betsy
Tentitive Seminar and Colloquium Assignments
Seminars:
10-3 Situation Theory and Situation Semantics
10-10 Rational Agency
10-17 Menzel
10-24 Discourse, Intention and Action
10-31 Foundations of Document Preparation
11-7 Phonology and Phonetics
11-14 Finite State Morphology
11-21 Computational Models of Spoken Language
1-9 Blair
1-16 Embedded Computation: Research on Situated Automata
1-23 Embedded Computation: Semantically Rational Computer Languages
1-30 Kirchner
2-6 Embedded Computation: Representation and Reasoning
2-13 Semantics of Computational Languages
2-20 Cleland
2-27 Linguistic Approaches to Computer Languages
3-6 Rooth
3-27 Grammatical Theory of Discourse Structure
4-3 AFT Lexical Representation Theory
4-10 Gawron
4-17 Lexical Initiative
4-24 Head-Driven Phrase Structure Grammar
5-1 Sells
5-8 Foundations of Grammar
5-15 Zalta
5-22 Visual Communication
Colloquia:
10-3 to 10-17: Situation Theory and Situation Semantics
10-24 to 11-7: Discourse, Intention and Action
11-14 to 11-21: Phonology & Phonetics, Finite State Morphology, &
Computational Models of Spoken Language
1-9 to 1-23: Embedded Computation & Document Preparation
1-30 to 2-13: Embedded Computation, Computational Language
Semantics, & Linguistic Approaches to Computer Languages
2-20 to 3-6: Rational Agency
3-27 to 4-10: Grammatical Theory of Discourse Structure, Lexical
Initiative, & AFT Lexical Representation Theory
4-17 to 4-24: Head-Driven Phrase Structure Grammar & Foundations of
Grammar
5-1 to 5-22: Visual Communication
-------
∂11-Sep-85 1741 EMMA@SU-CSLI.ARPA Newsletter September 12, No. 45
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 17:41:24 PDT
Date: Wed 11 Sep 85 16:56:02-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter September 12, No. 45
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
September 12, 1985 Stanford Vol. 2, No. 45
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, September 12, 1985
12 noon TINLunch
Ventura Hall ``Free Word Order in GPSG''
Conference Room by Arnold Zwicky
Discussion led by Hans Uszkoreit, SRI and CSLI
2:15 p.m. CSLI Talk
Ventura Hall ``Arithmetical Truth and Hidden Higher-Order Concepts''
Seminar Room Daniel Isaacson, Oxford University
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, September 19, 1985
12 noon TINLunch
Ventura Hall ``Some Remarks on the Relationship of Mind to
Conference Room Meaning and Language''
Discussion led by Daniel Isaacson, Oxford University
(Abstract on page 1)
2:15 p.m. CSLI Talk
Ventura Hall No talk this week
Seminar Room
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S TINLUNCH
``Some Remarks on the Relationship of Mind to Meaning and Language''
These remarks will be attempting to point toward a mind-based
approach to meaning and language, and to say something as to why one
might not be persuaded by considerations which have been taken as
disallowing such an approach and as requiring rather that
understanding of the phenomenon of language must underlie our
understanding of mind. This perspective is partially motivated by
focusing attention on progression of the infant from pre-verbal states
of mind to linguistic expression. Access to pre-verbal mental states
as required on this approach may be provided by psychoanalysis, in
particular by the work of Melanie Klein. In these terms, basic
cognitive and emotional development constitute two aspects of a single
process. --Daniel Isaacson
!
Page 2 CSLI Newsletter September 12, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
TALK
``Crossing the Rubicon: From a Physics of Dead Coordinate Spaces
to a Physics of Living Coordinate Spaces''
Dr. Peter Kugler, The Crump Institute for Medical Engineering, UCLA
Monday, September 23, 1985, 2:15pm
This talk will be about the Ecological (Gibsonian) view of
language, and will concentrate upon the conceptual tools which the
Ecological approach considers necessary for the study of language. A
more complete abstract will appear in next week's newsletter.
←←←←←←←←←←←←
ARTICULATORY PHONETICS
Osamu Fujimura
AT&T Bell Laboratories
A one-week course sponsored by the Linguistics Department and CSLI.
Place: Seminar Room, CSLI, Stanford University
Dates: Tuesday, September 17 - Monday, September 23
Hours: Tuesday 2-5, WThFM 10-12, 2-5
Course description:
The current status of articulatory studies will be reviewed with an
emphasis on recent findings using a computer-controlled x-ray
microbeam system. The movement patterns of articulatory organs such
as the tongue, the lower lip, the mandible and the velum reveal strong
prosodic effects on what usually are considered segmental gestures,
e. g. vowel gestures. The temporal organization of the
multidimensional articulatory patterns cannot be explained by the
conventional segment concatenation models. Some new principles of
phonetic organization will be examined, and their implications
concerning phonological representations of speech will be discussed.
A relatively large sample of microbeam (pellet movement) data will
be provided for student exercise, using the phonetics laboratory's
interactive computer facility and specially prepared analysis tools.
A two-hour lecture in the morning will be normally followed by
laboratory work using the graphics terminals during the afternoon
(and, if there is demand, during the evening as well).
No particular background knowledge will be presupposed, and there
is no registration fee. If you expect to attend, please contact Paul
Kiparsky at CSLI, Ventura Hall, Stanford University, Stanford, CA
94305 (net address: Kiparsky@CSLI.ARPA).
Course Outline
Tuesday 2-5 Anatomy: Articulatory organs, observation and
measurement methods
Wednesday 10-12 Physics: Linear systems and acoustics of speech
production; perception
2-5 Lab setup and basic demo
Thursday 10-12 Some observations from X-ray microbeam data
2-5 Exercise (Lab)
Friday 10-12 Temporal organization of speech
2-5 Exercise (Lab)
Monday 10-12 Models of speech production in relation to phonology
2-5 Overall discussion
-------
∂11-Sep-85 1742 BRESNAN@SU-CSLI.ARPA Valentina Zavarin
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 17:41:53 PDT
Date: Wed 11 Sep 85 17:38:11-PDT
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: Valentina Zavarin
To: researchers@SU-CSLI.ARPA
cc: zavarin@SU-CSLI.ARPA
Valentina Zavarin has returned from Paris, where she worked with
Greimas' group on a project comparing the semiotic and Schankian
models of story telling. She has worked on point of view,
discourse, and language from literary, linguistic, and
psychological perspectives, and would like to participate in
ongoing CSLI projects in these areas this year. Would anyone who
knows of relevant projects please send a message to Zavarin@csli,
with a cc to Susi?
Thanks--
Joan
-------
∂12-Sep-85 0323 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:klawe.sjrlvm1%ibm-sj.csnet@csnet-relay.arpa talk on razborov's theorem
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 03:23:11 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 12 Sep 85 03:21:45-PDT
Received: from csnet-relay by SU-SCORE.ARPA with TCP; Thu 12 Sep 85 03:21:36-PDT
Received: from ibm-sj by csnet-relay.csnet id ad03900; 12 Sep 85 6:18 EDT
Date: Wed, 11 Sep 85 14:47:28 PDT
From: Maria Klawe <klawe%ibm-sj.csnet@csnet-relay.arpa>
To: aflb.all@su-score.ARPA
Subject: talk on razborov's theorem
SPECIAL TALK: A complete proof of Razborov's theorem on clique functions
TIME: 10:30 - 12:30, Thursday, September 19
PLACE: MSRI Lecture Hall, MSRI, Berkeley
SPEAKER: Noga Alon, Tel-Aviv University (visiting IBM San Jose)
ABSTRACT:
A complete and self-contained proof of an improved version of Razborov's
theorem on the monotone circuit complexity of clique functions
will be presented. The improved lower bound is slightly less than
exponential, whereas Razborov's bound is just slightly more than
polynomial. This is joint work with Ravi Boppana.
∂12-Sep-85 0905 chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--Sept. 17
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 09:05:08 PDT
Received: from ucbcogsci.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA15013; Thu, 12 Sep 85 08:59:03 pdt
Received: by ucbcogsci.ARPA (5.5/4.48)
id AA15273; Thu, 12 Sep 85 09:03:50 PDT
Date: Thu, 12 Sep 85 09:03:50 PDT
From: chertok%ucbcogsci@Berkeley (Paula Chertok)
Message-Id: <8509121603.AA15273@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley
Subject: UCB Cognitive Science Seminar--Sept. 17
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, September 17, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Alan H. Schoenfeld, Education & Mathematics, UCB
TITLE: ``Obstacles To Making Sense of Mathematical
Notions, or, The Transfer Problem Rears its
Ugly Head Once Again''
It can be argued that the fundamental difficulty in mathemat-
ics learning is the transfer problem. That is, the power of
mathematics lies in the potential applicability of mathemati-
cal ideas to new situations. It doesn't matter whether the
idea is, for example, function, group, number, or triangle.
Once any particular mathematical entity is recognized as
belonging to an identified class of objects, everything known
about that class of objects applies to that entity. In such
abstaction resides much of the power and utility of mathemat-
ics. This paper explores some theoretical and some pragmatic
obstacles to students' abstraction of mathematical notions.
We look at two domains, whole number arithmetic and plane
geometry. Some parallels between the two domains are drawn,
to indicate that the processes of abstraction are similar in
both. In the case of number, we examine a theoretical para-
dox: the use of good ``hands on'' manipulatives to help stu-
dents make sense of base 10 addition and subtraction may make
it harder to understand the nature of ``number.'' In the case
of geometry, we discuss an empirical obstacle. When things
are compartmentalized in the curriculum, connections that we
would hope are ``natural'' turn out to be very hard to make.
--------------------------------------------------------------
UPCOMING TALKS
Sept. 24: Peter Pirolli, Education, UCB
Oct. 1: David Rumelhart, Cognitive Science, UCSD
Oct. 8: Terry Winograd, Computer Science, Stanford
Oct. 15: Ron Kaplan, Xerox PARC
Oct. 22: Lotfi Zadeh, Computer Science, UCB
Nov. 19: Richard Alterman, Computer Science, UCB
∂12-Sep-85 0908 @SU-CSLI.ARPA:chertok%ucbcogsci@Berkeley UCB Cognitive Science Seminar--Sept. 17
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 09:08:10 PDT
Received: from UCB-VAX.ARPA by SU-CSLI.ARPA with TCP; Thu 12 Sep 85 09:03:36-PDT
Received: from ucbcogsci.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA15013; Thu, 12 Sep 85 08:59:03 pdt
Received: by ucbcogsci.ARPA (5.5/4.48)
id AA15273; Thu, 12 Sep 85 09:03:50 PDT
Date: Thu, 12 Sep 85 09:03:50 PDT
From: chertok%ucbcogsci@Berkeley (Paula Chertok)
Message-Id: <8509121603.AA15273@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley
Subject: UCB Cognitive Science Seminar--Sept. 17
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, September 17, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Alan H. Schoenfeld, Education & Mathematics, UCB
TITLE: ``Obstacles To Making Sense of Mathematical
Notions, or, The Transfer Problem Rears its
Ugly Head Once Again''
It can be argued that the fundamental difficulty in mathemat-
ics learning is the transfer problem. That is, the power of
mathematics lies in the potential applicability of mathemati-
cal ideas to new situations. It doesn't matter whether the
idea is, for example, function, group, number, or triangle.
Once any particular mathematical entity is recognized as
belonging to an identified class of objects, everything known
about that class of objects applies to that entity. In such
abstaction resides much of the power and utility of mathemat-
ics. This paper explores some theoretical and some pragmatic
obstacles to students' abstraction of mathematical notions.
We look at two domains, whole number arithmetic and plane
geometry. Some parallels between the two domains are drawn,
to indicate that the processes of abstraction are similar in
both. In the case of number, we examine a theoretical para-
dox: the use of good ``hands on'' manipulatives to help stu-
dents make sense of base 10 addition and subtraction may make
it harder to understand the nature of ``number.'' In the case
of geometry, we discuss an empirical obstacle. When things
are compartmentalized in the curriculum, connections that we
would hope are ``natural'' turn out to be very hard to make.
--------------------------------------------------------------
UPCOMING TALKS
Sept. 24: Peter Pirolli, Education, UCB
Oct. 1: David Rumelhart, Cognitive Science, UCSD
Oct. 8: Terry Winograd, Computer Science, Stanford
Oct. 15: Ron Kaplan, Xerox PARC
Oct. 22: Lotfi Zadeh, Computer Science, UCB
Nov. 19: Richard Alterman, Computer Science, UCB
∂12-Sep-85 0932 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa FOCS reminders
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 09:32:53 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 12 Sep 85 09:26:31-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Thu 12 Sep 85 09:26:23-PDT
Received: by wisc-rsch.arpa; Thu, 12 Sep 85 10:57:54 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Thu, 12 Sep 85 02:16:17 cdt
Message-Id: <8509120716.AA02792@wisc-crys.arpa>
Received: from csnet-relay.arpa by wisc-crys.arpa; Thu, 12 Sep 85 02:16:11 cdt
Received: from uoregon by csnet-relay.csnet id aa02798; 12 Sep 85 3:00 EDT
Received: by uo-vax3.UONET (4.12/1.0.uoregon)
id AA10054; Wed, 11 Sep 85 17:35:51 pdt
Date: Wed, 11 Sep 85 17:35:51 pdt
From: Fall Conference Mail <focs%uoregon.csnet@csnet-relay.arpa>
Posted-Date: Wed, 11 Sep 85 17:35:51 pdt
To: theory@WISC-CRYS.ARPA
Subject: FOCS reminders
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
Some Reminders for Those Planning to Attend FOCS
October 21-23, Portland, OR.
1. The very reasonable room rates at the Marriott reflect a FOCS
discount of about 45%. HOWEVER, they are guaranteed only if
reservations are made 21 days in advance of arrival. Expect
to spend a lot more if you have not made such a reservation.
2. Up to 50 rooms are available at the even more dramatic student
discount. It is possible that these may be committed even
before the 21 day cutoff. Note that all room occupants must be
full-time students.
3. We are maintaining and distributing a roommate request list. If
you are interested, fill out and return the following to
focs@uoregon.CSNET
Name ..................................................
Institution ...........................................
Phone number ..........................................
Electronic address ....................................
Student [ ] Non-student [ ]
Desired number of room occupants (2,3,4) .......
4. Don't forget to compare, or ask your travel agent to compare,
any quoted airfare with that obtainable with the special FOCS
discount offered by United Airlines. Call 800-521-4041 and
give the FOCS account number 562T.
5. The DEADLINE for advance registration is September 27th.
∂12-Sep-85 1208 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Next week's PLANLUNCH -- notice change in date, place
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 12:08:38 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Thu 12 Sep 85 12:01:32-PDT
Date: Thu 12 Sep 85 11:57:32-PDT
From: LANSKY@SRI-AI.ARPA
Subject: Next week's PLANLUNCH -- notice change in date, place
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, rsimmons@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
vanLehn@XEROX.ARPA, araya@XEROX.ARPA, frayman@XEROX.ARPA,
suchman@XEROX.ARPA, weld@XEROX.ARPA, mittal@XEROX.ARPA, dekleer@XEROX.ARPA
Next week's planlunch will take place on WEDNESDAY at 11AM rather than
the usual Monday. We will resume Monday seminars after that. Also
notice the change in room -- EK242 is the old SRI-AI conference room.
We will return to the new conference room after next week as well.
See you there! -Amy Lansky
------------------------------------------------------------------------
SCRUFFY PLANNING
David Wilkins
SRI International AI Center
11:00 AM, WEDNESDAY, September 18
SRI International, Building E, Room EK242
Most of the talks in the planlunch series have been about "neat"
research. While neat researchers know they have a more
expressive formalism than do planners like SIPE, they have rarely
sat in front of a machine and watched their systems be overwhelmed
by the computational loads even simple representations can impose.
I'll defend scruffy planning (not to replace but to supplement neat planning),
show how SIPE represents a simple 6-room indoor world for Flakey, show
its solutions and use of computation, describe the kind of hacks needed to
make things run fast, describe pitfalls, and other scruffy stuff like that.
Only a small amount of time will be spent explaining SIPE, depending on
audience's desire.
-------
-------
∂12-Sep-85 1353 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp%ucbernie@Berkeley
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 13:53:17 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 12 Sep 85 13:49:07-PDT
Received: from UCB-VAX.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Sep 85 13:48:59-PDT
Received: from ucbernie.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA21130; Thu, 12 Sep 85 13:47:00 pdt
Received: by ucbernie.ARPA (5.5/5.3)
id AA08887; Thu, 12 Sep 85 13:51:11 PDT
Date: Thu, 12 Sep 85 13:51:11 PDT
From: karp%ucbernie@Berkeley (Richard Karp)
Message-Id: <8509122051.AA08887@ucbernie.ARPA>
To: aflb.all@su-score.ARPA
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley 642-0143
Tuesday, September 17 2:00
Vijaya Ramachandran
Finding a Minimum Feedback Arc Set in Reducible Graphs Using Maxflows and
Mincuts
Tuesday, September 17 4:00
Avi Wigderson
Ramsey-theoretic Lower Bounds in Parallel Computation
Wednesday, September 18 4:15 60 Evans
Joe Traub
An Introduction to Information-Based Complexity
Thursday, September 19
10:30
Noga Alon
The Monotone Circuit Complexity of Clique Functions
Tuesday, September 24 2:00
Umesh Vazirani
Sampling a Population with a Slightly Random Source
Tuesday, September 24 4:00
Adrian Ocneanu
Volumes of Tubes and Average Loss of Precision
Tuesday, October 1 2:00
Christos Papadimitriou
To Be Announced
Tuesday, October 1 4:00
Gary Miller
A New Method for Parallel Expression Evaluation
Joe Traub's lecture is on campus. All the others will be held in the MSRI
Lecture Hall.
∂12-Sep-85 1422 BARWISE@SU-CSLI.ARPA TGBBQ
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 14:21:53 PDT
Date: Thu 12 Sep 85 14:14:25-PDT
From: Jon Barwise <BARWISE@SU-CSLI.ARPA>
Subject: TGBBQ
To: Folks@SU-CSLI.ARPA
CSLI is having a late afternoon TGIF Bar-B-Que tomorrow. Ask Susi for
more details. Or just come. Jon
-------
∂12-Sep-85 1424 NEUMANN@SRI-CSLA.ARPA RISKS-1.10
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 14:24:37 PDT
Date: Thu 12 Sep 85 13:14:53-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.10
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS: ;
(Insert file: risks-1.10
-------
∂12-Sep-85 1540 NEUMANN@SRI-CSLA.ARPA RISKS-1.10
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 15:40:45 PDT
Date: Thu 12 Sep 85 13:26:05-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: RISKS-1.10
To: RISKS: ;
RISKS-FORUM Digest Thursday, 12 Sep 1985 Volume 1 : Issue 10
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Weizenbaum, etc.; even if SDI worked.... (John Shore)
SDI (John McCarthy)
More on SDI reliability (Martin Moore)
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
To: risks@sri-csl.ARPA
Subject: Weizenbaum, etc.; even if SDI worked....
Date: 12 Sep 85 11:11:13 EDT (Thu)
From: John Shore <epi-dc!shore@nrl-css.arpa>
It's tempting to respond to Weizenbaum by arguing against the general
proposition, "Don't do it if there's a way around it". After all, should we
refuse to develop bullet proof vests and to equip police officers with them
just because a criminal might approach from behind and stab them in the ass?
Assuming that a proposed defensive system will work, the relevant question
is what is the cost of developing it compared to the cost of getting around
it?
In the case of SDI, one should distinguish between defense against a few
missiles vs. defense against a massive attack. Either defense would be
enormously expensive to develop. If the goal of the attacker is to detonate
a few bombs (or threaten to do so), then it is obviously easier and cheaper
to get around SDI than through SDI. Here, Weizenbaum is probably right. If
the goal is massive or total destruction (including destruction of our
missile forces), then getting around SDI (assuming SDI works) does not
appear to be either easy or inexpensive. Here, Weizenbaum is probably
wrong. In this case, however, the premise is most likely also wrong.
Moreover, suppose that the premise is right -- i.e. SDI works perfectly. As
Parnas has pointed out, there's no way for anyone to establish this fact,
which shows the absurdity of arguments like "give us SDI and we will
dismantle our missiles".
------------------------------
Date: 12 Sep 85 0057 PDT
From: John McCarthy <JMC@SU-AI.ARPA>
Subject: SDI
To: risks@SRI-CSL.ARPA
Some remarks of mine about SDI on Stanford BBOARD have been referred
to. For the benefit of non-readers of that BBOARD, they mainly concerned
whether I, like Chris Stuart, should use the IJCAI platform to say something
about it. I said nothing in my lecture, but in my press conference, added
to my remarks on AI, the remark that there was no principle of computer
science that says that programs of any particular task cannot be written and
debugged. Not much interest was shown by the assembled press; there was
exactly one question on that point.
At the suggestion of Robert Jastrow, who is one of the main
scientific defenders of SDI, I made the same point in letters to three
Congressmen, said to be influential in the matter of SDI appropriations.
Now I shall say my opinion about SDI.
1. If it can be done, it should. If it affords complete protect,
that's great, and if it affords partial protection, that's good. The
balance of terror is a bad thing. Here are answers to some counter
arguments to its desirability. (a) Joe Weizenbaum says that it attempts a
technological solution to a problem that should be solved morally. Alas,
moral progress has been so slow that almost the only moral problems to be
even partially solved are those that can at least partially been turned into
technological problems. For example, the technology of contraception has
greatly reduced human unhappiness. (b) It is argued that the Soviets would
have to attack at the first sign of deployment. Every past imminent advance
by either side has in principle given the other side some temptation to
strike before it can be deployed. So far as we know, neither side has even
come close to giving in to such temptation. One reason is that the effect
of any advance is always subject to a probabilistic estimate, so temporizing
has always looked better than attacking. Even if SDI works very well, it
may be that no-one will be able to be sure that it is that good.
However, most likely the main reason has been is that neither side
ascribes the very worst intentions to the other with certainty. Each side
has always said, "Perhaps they don't actually mean to attack us. Why have a
nuclear war for sure instead of only a certain probability?" Anyway the
Soviets have experienced a period in which we had complete nuclear
superiority and didn't attack them.
2. My opinion is that if the physics of the problem permits a good
anti-missile defense the programs can be written and verified. However, it
will be quite difficult and will require dedicated work. It won't be done
by people who are against the whole project. Computer checked proofs of
program correctness will probably play some role. So will anticipating what
kind of bugs would be most serious and putting the biggest effort into
avoiding them. Having many people go over and discuss all the critical
parts of the program will also be important.
------------------------------
Date: Tue, 10 Sep 85 13:56:45 CDT
From: mooremj@EGLIN-VAX
Subject: More on SDI reliability
To: risks@sri-csl.arpa
Cc: soft-eng@mit-xx, lin@mit-mc, mooremj@eglin-vax
> From: Herb Lin <LIN@MIT-MC.ARPA>
> My primary complaint about your otherwise interesting table is that it
> assumes independent failure modes. I think it is much more likely
> that the effects of coupled failures are larger. In particular, given
> the failure of one platform, it is more likely that more than one will
> fail.
Good point. My original post did concern only statistically independent
failures. If I can be forgiven one more table, I'll address coupled failures.
Independent failures are caused by events isolated to a single platform,
e.g., electrical component failures. The occurrence of such a failure in
platform J does not affect the probability of a similar failure in platform K,
i.e., P(K|J) = P(K|~J) = P(K).
Coupled failures are failures such that the probability of failure is low in
any platform, but is greatly increased in all platforms when it occurs in
any one of them. For example, consider that a hostile power might develop a
new method for its missiles to escape detection. The probability that it will
fool any one platform may be low; but if it fools one platform it is likely to
fool more than one, perhaps all. For arbitrary platforms J and K, P(K|J) >>
P(K|~J).
The original false positive table is not affected by this, since it showed
the probability that at least one platform would fail. Coupled failures
do not change that probability, only the probability that if one fails, others
will (although it is true that while this country might be able to explain
away a single false positive, explaining a whole bunch of them could be a lot
tougher!)
The false negative case is where the kicker really comes in. The original
false negative table applies to independent failures. The following table
is structured similarly, but instead of using the probability of failure (Pn),
it uses the degree of coupling, Pn(K|J). This table shows, for a 100-platform
system, the probability of various numbers of successful responses, given
that at least one system has experienced a coupled failure.
Pn(K|J): .5 .6 .7 .8 .9 .95 .99
+-------------------------------------------------------
N: 0 | 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000
5 | 1.0000 1.0000 1.0000 1.0000 0.9746 0.5550 0.0033
10 | 1.0000 1.0000 1.0000 0.9973 0.5355 0.0265 0.0000
15 | 1.0000 1.0000 0.9998 0.9123 0.0677 0.0001 0.0000
20 | 1.0000 1.0000 0.9896 0.5200 0.0017 0.0000 0.0000
25 | 1.0000 0.9993 0.8740 0.1204 0.0000 0.0000 0.0000
30 | 1.0000 0.9822 0.5116 0.0097 0.0000 0.0000 0.0000
35 | 0.9988 0.8525 0.1465 0.0003 0.0000 0.0000 0.0000
40 | 0.9781 0.5054 0.0176 0.0000 0.0000 0.0000 0.0000
45 | 0.8426 0.1574 0.0008 0.0000 0.0000 0.0000 0.0000
50 | 0.5000 0.0219 0.0000 0.0000 0.0000 0.0000 0.0000
55 | 0.1574 0.0013 0.0000 0.0000 0.0000 0.0000 0.0000
60 | 0.0219 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
65 | 0.0012 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
70 | 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
For example, if the degree of coupling is 0.7 -- that is, if something that
causes failure in one platform has a 70% chance of causing failure in any
other platform -- then the probability is 51.16% that at least 30 of 100
platforms will respond correctly, 14.65% that at least 35 will, and so on,
GIVEN THAT THIS TYPE OF FAILURE OCCURS IN THE "FIRST" PLATFORM. Don't forget
that the probability that the first platform will fail is UNRELATED to the
probabilities in this table!
As far as the relative probabilities of independent and coupled failures,
I haven't a clue. The independent failures are the easiest to get a handle
on through reliability theory; the coupled failures may be the result of
unknown shortcomings in design, or due to unknown hostile actions. (There
is an old saying that there are always more unknown errors than known errors,
because known errors are limited, but unknown errors are unbounded by
definition!)
Martin Moore
mooremj@eglin-vax.arpa
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂12-Sep-85 1628 NEUMANN@SRI-CSLA.ARPA The foregoing mailings of RISKS-1.10
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 16:28:06 PDT
Date: Thu 12 Sep 85 15:32:24-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: The foregoing mailings of RISKS-1.10
To: RISKS-LIST@SRI-CSLA.ARPA
I apologize for the almost null message. I was debugging a macro to
automate the RISKS handling, and the ↑B to include a file did not get
properly escaped. That character is also used by the macro processor
as an internal break character. Yuk. Sorry. Thanks to those of you
commented on the RISKS of using message systems to run such a forum.
The real RISKS-1.10 was sent out a little later. I have ascertained that
some of you got the second message, some didn't. I try never to send
the Forum out during the day, to keep down net overhead, so this was
an exception. If you haven't gotten it in a while longer, try to FTP
it from SRI-CSL:<RISKS>RISKS-1.10. If you are gatewaylaid, then send
me a message. I don't see why some of you should have gotten it and
others not -- unless it is just net delay.
There are several of you who have requested to be added to the list
whose addresses I cannot answer (for various different reasons). I
generally try to find a net guru who can find a way through, so don't
give up if you read this second-hand.
Let me take this less formal opportunity, since I hope this message and the
near-null one will subsequently be deleted from your mail boxes, to thank
you all for your messages and contributions. Running this Forum has been
quite time consuming up until now (I am now largely automated), but very
rewarding. I am enjoying it immensely.
Peter
-------
∂12-Sep-85 1750 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 17:50:33 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 12 Sep 85 17:48:51-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Thu 12 Sep 85 17:48:48-PDT
Received: by wisc-rsch.arpa; Thu, 12 Sep 85 19:19:00 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Thu, 12 Sep 85 17:16:09 cdt
Message-Id: <8509122216.AA14968@wisc-crys.arpa>
Received: from csnet-relay.arpa by wisc-crys.arpa; Thu, 12 Sep 85 17:16:02 cdt
Received: from btl by csnet-relay.csnet id ab08838; 12 Sep 85 18:07 EDT
To: theory%uwisc.csnet-relay.csnet@csnet-relay.arpa
From: dsj%slepian.btl.csnet@csnet-relay.arpa
Date: Thu, 12 Sep EDT 1985 14:10
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
There will be no NP-Completeness Column appearing in the
December issue of J.ALGORITHMS, as I am currently revising
the first 14 or so columns for book publication.
If you have any corrections or updates on these that I might
not know about, please send them to
David S. Johnson
Room 2C-355
AT&T Bell Laboratories
Murray Hill, NJ 07974
or use computer mail (dsj.btl@csnet-relay or research!dsj).
I also continue to welcome new material. The column
will resume in the March 1986 issue.
∂13-Sep-85 0151 NEUMANN@SRI-CSLA.ARPA RISKS-1.11
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 01:51:38 PDT
Date: Fri 13 Sep 85 00:47:58-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.11
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-FORUM Digest Friday, 13 Sep 1985 Volume 1 : Issue 11
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
SDI and John McCarthy (Charlie Crummer)
SDI and Safeguard (John Mashey)
SDI and Robert Jastrow (Herb Lin)
Some financial disaster cases from Software Engineering Notes
(three contributions, totalling five reports)
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Thu, 12 Sep 85 19:00:29 PDT
From: Charlie Crummer <crummer@AEROSPACE.ARPA>
To: risks@sri-csl
Subject: SDI and John McCarthy
>Date: 12 Sep 85 0057 PDT
>From: John McCarthy <JMC@SU-AI.ARPA
>Subject: SDI
>To: risks@SRI-CSL.ARPA
>
>... there [is] no principle of computer
>science that says that programs of any particular task cannot be written and
>debugged.
Computer Science does not contain or deal with the principles operative
in the writing and debugging of large, nay, HUGE, eclectic, software
programs. This is the realm of Software Engineering. By a similar token
there is no principle of the theory of random processes that says that
the works of Shakespeare cannot be written by 1,000,000 monkeys pounding
1,000,000 typewriters either, in fact in principle that would be one way
of reproducing these works. No serious student of Shakespeare who knew
something about random processes would propose such an undertaking, of
course. A mathematician who knew nothing about typewriters and little
about Shakespeare, however, might if Ronald Reagan pursuaded him that
the problem should be worked by assigning 1,000,000,000,000 monkeys to
1,000,000,000,000 typewriters. In software engineering as well as
mechanical engineering there is the concept of feasibility to be considered.
> Now I shall say my opinion about SDI.
>
>If it can be done, it should.
If you had a gun wouldn't you be more afraid to face a gunman with
a bullet-proof vest than one without? If he began deliberately to
put this vest on as he stood before you with his gun leveled at you
wouldn't you be inclined to fire before he got the vest on?
>If it affords complete protection that's great,
>and if it affords partial protection, that's good.
You speak in the present tense but "it" does not exist! How can
a non-existence afford anything? At least one of the basic questions
is whether it can be made at all.
>The balance of terror is a bad thing.
Yes, and SDI would only enhance the terror. The "civilized" world has
no defensive answer to the terrorists in such mundane places as on airliners,
let alone in space, and such is not in the offing.
>Here are answers to some counter
>arguments to its desirability. (a) Joe Weizenbaum says that it attempts a
>technological solution to a problem that should be solved morally.
MUST be solved between the terrorizer and terrorizee. When someone's
out to get you there's no place to hide. (D. Corleone)
>Alas,
>moral progress has been so slow that almost the only moral problems to be
>even partially solved are those that can at least partially been turned into
>technological problems.
Not true, viz. cannibalism and slavery.
>For example, the technology of contraception has
>greatly reduced human unhappiness.
What evidence do you have of that?
>(b) It is argued that the Soviets would
>have to attack at the first sign of deployment. Every past imminent advance
>by either side has in principle given the other side some temptation to
>strike before it can be deployed. So far as we know, neither side has even
>come close to giving in to such temptation. One reason is that the effect
>of any advance is always subject to a probabilistic estimate, so temporizing
>has always looked better than attacking. Even if SDI works very well, it
>may be that no-one will be able to be sure that it is that good.
You may be safe in saying that but I hope our leaders are not so cavalier.
Most serious strategy is based on "worst case" scenarios.
> However, most likely the main reason has been is that neither side
>ascribes the very worst intentions to the other with certainty. Each side
>has always said, "Perhaps they don't actually mean to attack us. Why have a
>nuclear war for sure instead of only a certain probability?" Anyway the
>Soviets have experienced a period in which we had complete nuclear
>superiority and didn't attack them.
>
>2. My opinion is that if the physics of the problem permits a good
>anti-missile defense the programs can be written and verified. However, it
>will be quite difficult and will require dedicated work. It won't be done
>by people who are against the whole project. Computer checked proofs of
>program correctness will probably play some role. So will anticipating what
>kind of bugs would be most serious and putting the biggest effort into
>avoiding them. Having many people go over and discuss all the critical
>parts of the program will also be important.
>
Whether the physics of the problem admits a good anti-missile defense
is a paramount question. It will take much more than dedicated climbing
of the automatic proof of correctness "tree" to get to the "moon" of
an "astrodome" over the U.S. a la Reagan's definition of strategic
defense.
--Charlie
------------------------------
Date: Thu, 12 Sep 85 22:56:02 pdt
From: mips!mash@glacier (John Mashey)
To: Glacier!risks@sri-csl.ARPA
Subject: SDI and Safeguard
I used to work with many of the people at Bell Labs who worked on the
Safeguard ABM; they were competent people who knew how to build complex
systems. Maybe there were some who believed that it was actually possible
to build a reliable, deployable, maintainable ABM that one could expect to
work in real use; if so, I never met any; most folks did not so believe,
and said so. [They did believe that you could shoot down missiles in
well-controlled tests, because they'd done it; they just didn't believe
it would work when it needed to.]
------------------------------
Date: Thu, 12 Sep 85 20:08:22 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
Subject: SDI and Robert Jastrow
To: JMC@SU-AI.ARPA
cc: LIN@MIT-MC.ARPA, risks@SRI-CSL.ARPA
From: John McCarthy <JMC at SU-AI.ARPA>
At the suggestion of Robert Jastrow, who is one of the main
scientific defenders of SDI, I made the same point in letters to three
Congressmen, said to be influential in the matter of SDI appropriations.
Robert Jastrow is certainly a defender of the SDI, but he has admitted
publically in his own Congressional testimony that he does NOT carry
out scientific analyses of anything related to SDI. He hardly counts
as a "scientific defender."
------------------------------
Date: Fri 13 Sep 85 00:22:19-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Some financial disaster cases from Software Engineering Notes
To: RISKS@SRI-CSLA.ARPA
I hope that the RISKS Forum will not degenerate into only an SDI Forum, so I
thought I would counterbalance this issue with a new topic. I have
resurrected a contribution from the July 1985 SIGSOFT SEN, and also preview
some newer cases that will appear in the October 1985 SEN (which is just
about ready to go to press). (The few of you who are ACM SIGSOFT members
please pardon me for the duplications.)
-------
[FROM ACM Software Engineering Notes vol 10 no 3, July 1985]
Disasters Anonymous 1: A Rose is Arose is (Three) Z-Rose
Now and then I get a story that I cannot print. (I do have a few, but don't
ask. I have of course conveniently forgotten them all.) Here, is one that can
be printed -- although its author must remain anonymous. Note that the case of
the three extra zeroes resulting from two different assumptions about the human
interface bears an eerie resemblance in cause to the case of the shuttle laser
experiment, which follows after this one. [PGN]
A group within my company had a policy of dealing only in multiples
of one thousand dollars, so they left off the last three digits in
correspondence to the wire transfer area to make their job easier.
Other groups, however, had to write out the full amount since they did
not always deal with such nice round numbers. One day, a transaction
was processed that had a value of $500,000. The person who entered the
transaction thought that it was from the group who dealt in multiples
of $1000 and entered it as $500,000,000. Of course, this was not the case,
so a $500,000 transaction became a $500,000,000 one.
The only thing that prevented a disaster was that it was sent to a small
company that called back to verify the amount, and the error was then
caught. However, this was a Federal Reserve transaction and the funds
had been transferred, but the timing was good and the transaction was
backed out before it became a disaster. My opinion is that such critical
software should have caught the error before the wire was sent to the
Federal Reserve.
Another error in a Federal Reserve transfer had to do with multiple
transactions per communications transfer. In this case, the Federal
Reserve software put a pair of nulls in the data that should have been
translated as blanks. However, they were stripped out and a $200,000,000
incoming wire lost. To maintain the Fed balance, money was purchased
to cover a deficit that didn't exist -- since the money was a credit.
This was a substantial monetary loss because of inadequately tested
software.
-------
[FROM ACM Software Engineering Notes vol 10 no 5, October 1985]
Disasters Anonymous 2: Financial Losses
Our anonymous contributor from SEN 10 3 (July 1985) has come through again.
Since I sent some disaster reports to you in May, another one has occurred.
This one caused some financial loss and acute headaches among managers.
Most large banks subscribe to the Federal Reserve's funds transfer system,
frequently referred to as "Bankwire". Our system that connects to Fedwire
was being upgraded with a new DDA interface to the host to help protect
against overdrafts. During a review, it was determined that the software
was not quite ready, but should be okay to put into production two days
later. I cautioned them against doing so since not all of the bugs had been
resolved, and the software had not been "stress tested" (or whatever phrase
you wish to use about testing that ensures that it will work in production).
The first day of production went fine. However, the main file in the new
software was an ISAM file that had degraded significantly during the first
day. On the second day, that file continued to fragment and started to
consume a large amount of the system resources. This slowed response time
so much that by the end of the banking day, we still had hundreds of wires
to send to the Federal Reserve. We had to request extensions every half
hour for hours to try and squeeze the transactions through the system so
that the money would get to our customers.
In addition, the response-time problem and other bugs in the software
prevented us from knowing our Federal Reserve balance. Since we must
maintain some 150 million dollars in our Fed "checking account", this lack
of information could cause significant financial loss as 1.5 billion dolars
were posted that day and we were off by hundreds of millions of dollars at
first.
Another part of this disaster is that the slow response time caused one
program to assume that the host was down. When a transaction finally went
through, our system would transmit the DDA information, but the host did not
acknowledge that they already had the wire. Thus a large number of wires
were being "double posted" (money sent twice). At the end of the day, tens
of millions had been double posted.
As of this writing, the Fed balance had been straightened out, but not all
of the double postings had been recovered. Note that at current interest
rates, a bank loses $350 per day per million dollars of unused money.
-------
[FROM ACM Software Engineering Notes vol 10 no 5, October 1985]
Disasters Anonymous 3: Insurance, Reinsurance, and Rereinsurance
Perhaps anonymity is contagious. Re: reinsurance, here is
another letter from a different contributor.
I'm newly receiving SEN and found the ``war stories'' quite interesting.
Here are three more. I would prefer anonymity should you choose to print
these.
This first is hearsay (from a former co-worker). Apparently he and his
wife had a joint account with a $300 balance. They needed $200 in cash, but
due to miscommunication they both made $200 withdrawals - she at a teller's
window (cage?) and he at an ATM (automatic teller machine) - within minutes
of each other. When the dust settled they found that their account had a
zero balance: the first $200 withdrawal left a $100 balance, the second
should have left a negative balance of $100, but the computer generated a
$100 credit to offset the shortfall. The icing on the cake was my friend's
inability to explain/convince the bank of this situation and have them accept
restitution.
I need to be circumspect about this second story -- it might well have
involved fraud. While a consultant, I was hired to review a reinsurance
agreement. The reinsurance industry is an old-boys, ``handshake is my bond''
industry as insurors frequently offset their risk by selling it (reinsuring)
to other insurors. That is, I insure your building for $10,000,000 and
re-sell all or part of that risk to another firm. Apparently, late one
Monday morning (nearly 11:00 a.m. EST), my client got notice across his
computer network from another firm that it was reinsuring (i.e. off-loading
risk) to my client to the tune of several million dollars. The message was
time-dated Friday evening (6:00 P.M., WST). As ``luck'' would have it the
property in question had suffered a catastrophic loss over the weekend. The
bottom line was that the message had been sent directly (not through any of
the store-and-forward services) and the time-date was thus determined by the
clock-calendar on the sender's computer. Need I say more?
Finally, a story told to me ``out of school'' by a friend at one of the
nation's largest insurance companies. They apparently are involved in so
many reinsurance deals that it turned out that they were reinsuring
themselves. I.e., Jones reinsured with Smith who reinsured with Brown who
reinsured with White who reinsured with Smith. Smith, it turned out was
paying both Brown and White commissions for accepting his own risk. The
computer system was not designed to look beyond the current customer,
neglecting the loop.
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂13-Sep-85 0307 NET-ORIGIN@MIT-MC.ARPA Enter on BBoard
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 03:07:48 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 SEP 85 06:04:43 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 13 Sep 85 06:05-EDT
Received: from WISCVM.ARPA by MIT-MC.ARPA 13 Sep 85 06:02:50 EDT
Received: from (#D1Z)DDATHD21.BITNET by WISCVM.ARPA on 09/13/85 at
05:04:04 CDT
Date: 13 Sep 1985, 12:00 CEST
To: <#D1Z%DDATHD21.BITNET@WISCVM.ARPA> ,
<PHILOSOPHY-OF-SCIENCE-REQUEST@MIT-MC> ,
<PHILOSOPHY-OF-SCIENCE@MIT-MC> ,
<JCMa@MIT-MC>
From: <#D1Z%DDATHD21.BITNET@WISCVM.ARPA>
Subject: Enter on BBoard
UserID #D1Z Node DDATHD21 Network EARN (= BITNET)
(Beware of the number sign (#). It's part of my UserID!)
In the beginning of August, I requested to be entered into the mailing
list concerning philosophy of science.
Up to now I didn't receive any mail concerning this subject, nor did I
receive an acknowledge.
Could anybody tell me something about this bboard?
Mid freundlische Griess/With kind regards
Wilhelm Mueller
TH Darmstadt, HRZ, Beratung AB
Petersenstr. 30
D-6100 Darmstadt
Federal Republic of Germany
Tel +49/6151/16-3050)
∂13-Sep-85 0855 ullman@su-aimvax.arpa meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 08:54:51 PDT
Received: by diablo with Sendmail; Tue, 3 Sep 85 13:03:43 pdt
Date: Tue, 3 Sep 85 13:03:43 pdt
From: Jeff Ullman <ullman@diablo>
Subject: meeting
To: nail@diablo
tomorrow, 11AM.
Shukey will talk about recent work of his that may imply
something about optimal join ordering.
∂13-Sep-85 1117 BETSY@SU-CSLI.ARPA New Charge for Specially Processed Checks
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 11:17:38 PDT
Date: Fri 13 Sep 85 11:13:43-PDT
From: Betsy Macken <BETSY@SU-CSLI.ARPA>
Subject: New Charge for Specially Processed Checks
To: folks@SU-CSLI.ARPA
The Stanford Accounting Office has announced that as of October 1
they will charge $7.50 for each check that is "walked through".
In the past, CSLI has had to walk through checks quite frequently
to get them through Stanford's system with just a few days notice
-- usually in relation to operant funds. Be aware that in the
future we will have to charge your project's operant funds for
checks we have to walk through.
Betsy
-------
∂13-Sep-85 1209 @MIT-MC.ARPA:Ghenis.pasa@XEROX.ARPA Is the Phi of Sci list alive?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 12:09:50 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 SEP 85 15:05:39 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 13 Sep 85 15:06-EDT
Received: from Xerox.ARPA by MIT-MC.ARPA 13 Sep 85 15:01:50 EDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 13 SEP 85 12:03:32 PDT
Date: 13 Sep 85 11:18 PDT
From: Ghenis.pasa@Xerox.ARPA
Subject: Is the Phi of Sci list alive?
In-reply-to: <#D1Z@DDATHD21.BITNET>'s message of 13 Sep 1985, 12:00 CEST
To: #D1Z%DDATHD21.BITNET@WISCVM.ARPA
cc: PHILOSOPHY-OF-SCIENCE-REQUEST@MIT-MC.ARPA,
PHILOSOPHY-OF-SCIENCE@MIT-MC.ARPA, JCMa@MIT-MC.ARPA
Message-ID: <850913-120332-2639@Xerox>
I have been on the Philosophy of Science list for several months now,
and as far as I can tell it is dead, dead, dead... Hope I'm wrong and
it's just a problem with my link to the list.
If anyone can report any signs of life or other relevant info, please
do.
∂13-Sep-85 1218 YAMARONE@SU-CSLI.ARPA TGIF TODAY @ 4:00
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 12:18:42 PDT
Date: Fri 13 Sep 85 12:13:37-PDT
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: TGIF TODAY @ 4:00
To: folks@SU-CSLI.ARPA
Folks,
There will be a TGIF today beginning at 4:00 pm on the patio at CSLI.
All are invited to attend and BYOB-ing is optional. Chips, drinks and
any other victual delights would be welcomed as the Bar-B-Que mistress
will be preparing CHICKEN for all. And you all know how much I LOVE
CCCCCCCCCCC H H IIIIIII CCCCCCCCC K K EEEEEEEE N N
C H H I C K K E N N N
C H H I C K K E N N N
C H H I C K K E N N N
C HHHHHHHHHH I C KKK EEEEEEE N N N
C H H I C K K E N N N
C H H I C K K E N NN
C H H I C K K E N N
CCCCCCCCCCC H H IIIIIII CCCCCCCCC K K EEEEEEEE N N
So, plan on an afternoon of mingling and merriment.....put your
superstitions aside ......and we'll be seeing you at 4:00 for another grand
TTTTTTTTTTTTTTTTT GGGGGGGGGG IIIII FFFFFFFFFFFFFF
T G G I F
T G G I F
T G I F
T G I F
T G I FFFFFFFFF
T G GGGGGG I F
T G G I F
T G G I F
T G G I F
T GGGGGGGGGG IIIII F
Care of your friends and co-workers at
CCCCCCCC SSSSSS LLLLL IIIII
C C S S L I
C S L I
C S L I
C S L I
C SSSSS L I
C S L I
C S L I
C S L I
C C S S L L I
CCCCCCCC SSSSSS LLLLLLLLLLLLL IIIII
Tell a friend and bring them along!!!!
Good food, Good drink, you can't go wrong!!!!
-------
∂13-Sep-85 1302 YAMARONE@SU-CSLI.ARPA ONE EXTRA TURKEY SANDWICH:2.50
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 13:02:51 PDT
Date: Fri 13 Sep 85 12:59:19-PDT
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: ONE EXTRA TURKEY SANDWICH:2.50
To: folks@SU-CSLI.ARPA
There happens to be one extra turkey sandwich on light rye
available at the front desk.
Don't let this go to waste....
Eat now!!!
The Ventura Sandwich Corp.
IGNORE THIS MESSAGE IF RECEIVED LATER THAN 1:30 PM. THANK YOU!!
-------
∂13-Sep-85 1505 NEUMANN@SRI-CSLA.ARPA RISKS-1.12
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 15:05:19 PDT
Date: Fri 13 Sep 85 13:44:10-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.12
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-FORUM Digest Friday the 13 Sep 1985 Volume 1 : Issue 12
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Wire-Transfer Risks; Risk of Non-application of Technology (Jerry Saltzer)
Date-Time stamps (and errors therein) (Ted M P Lee)
JMC's remarks (Joseph Weizenbaum)
Subjective Factors in Risk Assessment (Lynne C. Moore)
Moral vs. Technological Progress (Charlie Crummer)
[*** MODERATOR'S NOTE. SOME OF THE SDI-RELATED DISCUSSION MAY BE
DEGENERATING INTO A NONCONVERGENT ITERATIVE LOOP. LET'S TRY TO STICK A
LITTLE MORE TO COMPUTER-RELATED ISSUES, ALTHOUGH I RECOGNIZE THAT THE
TECHNICAL ISSUES MAY BE OVERWHELMED BY NONTECHNICAL ISSUES. BUT PLEASE DO
NOT INTERPRET THIS AS AN ATTEMPT TO SQUELCH MEANINGFUL DISCUSSION. PGN ***]
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Fri, 13 Sep 85 10:51 EDT
From: Saltzer@MIT-MULTICS.ARPA
Subject: Wire-Transfer Risks; Risk of Non-application of Technology
To: RISKS FORUM <RISKS@SRI-CSL.ARPA> (Peter G. Neumann, Coordinator)
Re: Wire-Transfer Risks
1) The current (September, 1985) issue of IEEE Communications magazine
on page 23 suggests that it may be typical in the wholesale financial
business to carry transactions in thousands of dollars rather than in
(ones of) dollars. If so, you would think that the people responsible
for software in that business would check and recheck their specs and
the human engineering across those interfaces where dividing or
multiplying by 1000 is a possibility, wouldn't you?
2) The comment that current money prices lead to losses of about $350
per day for each mislaid million dollars seems to have been intended to
suggest that such mistakes are unacceptable. The people in the
wholesale money movement business draw an opposite conclusion: since
they can quantify their exposure so precisely, they can decide
rationally when the loss rate has become unacceptable and it is thus
worth paying someone to develop a more error-free system. (For the
price of a contract to SRI to develop a verified 1000-line program one
could probably afford to mislay IBM's entire revenue stream for a week.)
Re: Risk of Non-application of Technology
For another economically quantifiable example, the early reports on the
creation of the SABRE airline reservation system by American Airlines
explicitly mentioned a business decision, with two alternatives: invest
in two more Boeing 707's, or in developing SABRE. The first approach
provided more spare seat-mile capacity that could thus be managed with
less precision; the second offered the hope of better management of
available seat-mile capacity. Two other considerations that were
explicitly mentioned were the cost of customer disatisfaction when
reservations were dishonored (accidental overbooking, as contrasted with
intentional overbooking, was a rampant problem at the time) and the cost
to the company in lost revenue if the prospective computer were to go
down for several hours or if the entire contents of the disks were lost.
The decision to develop SABRE thus represents an example of up-front
assessment of the risk of non-application of technology, compared with
the risk of applying it.
------------------------------
Date: Fri, 13 Sep 85 12:15 EDT
From: TMPLee@MIT-MULTICS.ARPA
Subject: Date-Time stamps (and errors therein)
To: Risks@SRI-CSL.ARPA
It was an interesting coincidence that the latest Risks←Forum had a
piece related to the correctness of the time-stamp on messages. About
two days ago I logged on late (about half-past midnight, Central time)
and started going through my electronic in-basket. One of the messages
struck me: its header was time-stamped 03:56 EDT -- how could I
possibly be reading it two and a half-hours before it was sent? (yes,
the dates were right -- it wasn't from the previous night/early-AM.)
Eventually got a copy of the original from its author. The key to the
mystery is that Multics does a time-zone conversion on most (but not
all) time fields in incoming message headers. The original message's
time-zone was clearly marked as PDT, so multics dutifully added three
hours and gave me the time in EDT. When we (I and a multics guru) first
looked at just the multics version we speculated that perhaps multics
had taken the message's time-zone as GMT, which I think would have given
the same result. I also thought perhaps since the original was before
midnight and the result after, that might have been the cause. In the
process of writing this entry for the Risks forum I looked at the
original message one more time, and it struck me: for some reason the
ISI clock had been set to run on Eastern Time (00:56) but the ISI mailer
software (or something else there) thought it was keeping Pacific, hence
the PDT tag. What was further confusing was the fact that I looked at
several other messages from ISI from about the same period (two to four
days ago) and some came out right and some not. Sounds like a good
ingredient for a mystery story, at least.
------------------------------
Date: Fri 13 Sep 85 12:57:15-EDT
From: Joseph Weizenbaum <JOSEPH@MIT-XX.ARPA>
Subject: JMC's remarks
To: risks@SRI-CSL.ARPA
Contrary to John McCarthy's inference that I hold to the "general
proposition, 'Don't do it if there's a way around it'", I think that
proposition to be (even purely logically) absurd. The "way around it"
would be another "it" to which the rule would apply, and so on.
Another instance of John putting words in my mouth I didn't (and wouldn't)
utter is his "Joe Weizenbaum says that [SDI] attempts a technological
solution to a problem that should be solved morally". He makes it easy for
himself to score a point by pointing to the slowness of "moral progress"
and so on. I believe I wrote that SDI is a technological fix for a problem
that is primarily political, cultural, economic, and so on, and that it has
to be attacked in these contexts, that we must actually confront the
problem of how peoples who organize their societies differently from one
another can peacefully share the same globe. That is considerably
different from saying the problem should be "solved morally". The trouble
with technological fixes is often, and I think in this case, that they give
the impression the problem has been dealt with and that no further efforts
to deal with it are necessary. In the present instance the spread of such
an impression with respect to the peaceful coexistence of the Western and
the Eastern block nations could be fatal to the whole world.
------------------------------
Date: Fri, 13 Sep 85 13:48:04 CDT
From: moorel@EGLIN-VAX
Subject: Subjective Factors in Risk Assessment
To: RISKS@SRI-CSL.ARPA
There is a very interesting article about various types of risks and
the way that people perceive them in the October issue of ←Science←85←. In
particular, it makes a couple of points that I feel are quite relevant to this
forum's discussions. First, that people respond to risks differently depending
on whether the risk is presented as a positive or a negative risk. "Because
losses loom larger than gains, we are more willing to gamble to avoid them."
Second, it points out that most people are less concerned and aware of the risksof things over which they feel that they have some control. "If we can't be
certain about the risks we face, we at least want to have some control over the
technologies and activities that produce them."
When we look for examples of the risks of using computer technology vs.
the risks of not using computer technology, we ought to keep these two ideas in
mind, and ask ourselves whether we are being truly objective about the risks
involved or are we letting other, subjective factors influence our judgement. I
recommend this article for your reading.
Lynne C. Moore (MOOREL AT EGLIN-VAX.ARPA)
------------------------------
Date: Fri, 13 Sep 85 10:56:21 PDT
From: Charlie Crummer <crummer@AEROSPACE.ARPA>
To: risks@sri-csl
Subject: Moral vs. Technological Progress
> From: McNelly.OsbuSouth@Xerox.ARPA
> In-Reply-to: NEUMANN%SRI-CSLA:ARPA's message of 13 Sep 85 01:19:23 PDT
> (Friday)
>>>Alas,
>>>moral progress has been so slow that almost the only moral problems to be
>>>even partially solved are those that can at least partially been turned into
>>>technological problems.
>>Not true, viz. cannibalism and slavery.
> Actually, it's my understanding that the demise of slavery was due to
> technological advances which made slavery economically unfeasible. The
> invention of the cotton gin, for example, made it only a matter of time
> here in the US before slavery died out. As far as cannibalism goes, I'd
> say that was more caused by Western culture steam-rolling over the
> cannibals.
> -- John --
Actually McCarthy's original comment presupposes that moral and technological
progress are comparable. It is that assumption that I disagree with. Ethics
and the attendant morality provide the context within which all activity, and
in particular technological progress, exists. Morality and technology are
not substitutes for one another and moral progress is not dependent on
technology nor vice versa. There is always technological progress attendant
to moral progress just because there is always technological progress.
--Charlie
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂13-Sep-85 1636 NEUMANN@SRI-CSLA.ARPA RISKS-1.12
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 13 Sep 85 16:36:07 PDT
Date: Fri 13 Sep 85 14:28:03-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.12
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-FORUM Digest Friday the 13 Sep 1985 Volume 1 : Issue 12
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Wire-Transfer Risks; Risk of Non-application of Technology (Jerry Saltzer)
Date-Time stamps (and errors therein) (Ted M P Lee)
JMC's remarks (Joseph Weizenbaum)
Subjective Factors in Risk Assessment (Lynne C. Moore)
Moral vs. Technological Progress (Charlie Crummer)
[*** MODERATOR'S NOTE. SOME OF THE SDI-RELATED DISCUSSION MAY BE
DEGENERATING INTO A NONCONVERGENT ITERATIVE LOOP. LET'S TRY TO STICK A
LITTLE MORE TO COMPUTER-RELATED ISSUES, ALTHOUGH I RECOGNIZE THAT THE
TECHNICAL ISSUES MAY BE OVERWHELMED BY NONTECHNICAL ISSUES. BUT PLEASE DO
NOT INTERPRET THIS AS AN ATTEMPT TO SQUELCH MEANINGFUL DISCUSSION. PGN ***]
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Fri, 13 Sep 85 10:51 EDT
From: Saltzer@MIT-MULTICS.ARPA
Subject: Wire-Transfer Risks; Risk of Non-application of Technology
To: RISKS FORUM <RISKS@SRI-CSL.ARPA> (Peter G. Neumann, Coordinator)
Re: Wire-Transfer Risks
1) The current (September, 1985) issue of IEEE Communications magazine
on page 23 suggests that it may be typical in the wholesale financial
business to carry transactions in thousands of dollars rather than in
(ones of) dollars. If so, you would think that the people responsible
for software in that business would check and recheck their specs and
the human engineering across those interfaces where dividing or
multiplying by 1000 is a possibility, wouldn't you?
2) The comment that current money prices lead to losses of about $350
per day for each mislaid million dollars seems to have been intended to
suggest that such mistakes are unacceptable. The people in the
wholesale money movement business draw an opposite conclusion: since
they can quantify their exposure so precisely, they can decide
rationally when the loss rate has become unacceptable and it is thus
worth paying someone to develop a more error-free system. (For the
price of a contract to SRI to develop a verified 1000-line program one
could probably afford to mislay IBM's entire revenue stream for a week.)
Re: Risk of Non-application of Technology
For another economically quantifiable example, the early reports on the
creation of the SABRE airline reservation system by American Airlines
explicitly mentioned a business decision, with two alternatives: invest
in two more Boeing 707's, or in developing SABRE. The first approach
provided more spare seat-mile capacity that could thus be managed with
less precision; the second offered the hope of better management of
available seat-mile capacity. Two other considerations that were
explicitly mentioned were the cost of customer disatisfaction when
reservations were dishonored (accidental overbooking, as contrasted with
intentional overbooking, was a rampant problem at the time) and the cost
to the company in lost revenue if the prospective computer were to go
down for several hours or if the entire contents of the disks were lost.
The decision to develop SABRE thus represents an example of up-front
assessment of the risk of non-application of technology, compared with
the risk of applying it.
------------------------------
Date: Fri, 13 Sep 85 12:15 EDT
From: TMPLee@MIT-MULTICS.ARPA
Subject: Date-Time stamps (and errors therein)
To: Risks@SRI-CSL.ARPA
It was an interesting coincidence that the latest Risks←Forum had a
piece related to the correctness of the time-stamp on messages. About
two days ago I logged on late (about half-past midnight, Central time)
and started going through my electronic in-basket. One of the messages
struck me: its header was time-stamped 03:56 EDT -- how could I
possibly be reading it two and a half-hours before it was sent? (yes,
the dates were right -- it wasn't from the previous night/early-AM.)
Eventually got a copy of the original from its author. The key to the
mystery is that Multics does a time-zone conversion on most (but not
all) time fields in incoming message headers. The original message's
time-zone was clearly marked as PDT, so multics dutifully added three
hours and gave me the time in EDT. When we (I and a multics guru) first
looked at just the multics version we speculated that perhaps multics
had taken the message's time-zone as GMT, which I think would have given
the same result. I also thought perhaps since the original was before
midnight and the result after, that might have been the cause. In the
process of writing this entry for the Risks forum I looked at the
original message one more time, and it struck me: for some reason the
ISI clock had been set to run on Eastern Time (00:56) but the ISI mailer
software (or something else there) thought it was keeping Pacific, hence
the PDT tag. What was further confusing was the fact that I looked at
several other messages from ISI from about the same period (two to four
days ago) and some came out right and some not. Sounds like a good
ingredient for a mystery story, at least.
------------------------------
Date: Fri 13 Sep 85 12:57:15-EDT
From: Joseph Weizenbaum <JOSEPH@MIT-XX.ARPA>
Subject: JMC's remarks
To: risks@SRI-CSL.ARPA
Contrary to John McCarthy's inference that I hold to the "general
proposition, 'Don't do it if there's a way around it'", I think that
proposition to be (even purely logically) absurd. The "way around it"
would be another "it" to which the rule would apply, and so on.
Another instance of John putting words in my mouth I didn't (and wouldn't)
utter is his "Joe Weizenbaum says that [SDI] attempts a technological
solution to a problem that should be solved morally". He makes it easy for
himself to score a point by pointing to the slowness of "moral progress"
and so on. I believe I wrote that SDI is a technological fix for a problem
that is primarily political, cultural, economic, and so on, and that it has
to be attacked in these contexts, that we must actually confront the
problem of how peoples who organize their societies differently from one
another can peacefully share the same globe. That is considerably
different from saying the problem should be "solved morally". The trouble
with technological fixes is often, and I think in this case, that they give
the impression the problem has been dealt with and that no further efforts
to deal with it are necessary. In the present instance the spread of such
an impression with respect to the peaceful coexistence of the Western and
the Eastern block nations could be fatal to the whole world.
------------------------------
Date: Fri, 13 Sep 85 13:48:04 CDT
From: moorel@EGLIN-VAX
Subject: Subjective Factors in Risk Assessment
To: RISKS@SRI-CSL.ARPA
There is a very interesting article about various types of risks and
the way that people perceive them in the October issue of ←Science←85←. In
particular, it makes a couple of points that I feel are quite relevant to this
forum's discussions. First, that people respond to risks differently depending
on whether the risk is presented as a positive or a negative risk. "Because
losses loom larger than gains, we are more willing to gamble to avoid them."
Second, it points out that most people are less concerned and aware of the risksof things over which they feel that they have some control. "If we can't be
certain about the risks we face, we at least want to have some control over the
technologies and activities that produce them."
When we look for examples of the risks of using computer technology vs.
the risks of not using computer technology, we ought to keep these two ideas in
mind, and ask ourselves whether we are being truly objective about the risks
involved or are we letting other, subjective factors influence our judgement. I
recommend this article for your reading.
Lynne C. Moore (MOOREL AT EGLIN-VAX.ARPA)
------------------------------
Date: Fri, 13 Sep 85 10:56:21 PDT
From: Charlie Crummer <crummer@AEROSPACE.ARPA>
To: risks@sri-csl
Subject: Moral vs. Technological Progress
> From: McNelly.OsbuSouth@Xerox.ARPA
> In-Reply-to: NEUMANN%SRI-CSLA:ARPA's message of 13 Sep 85 01:19:23 PDT
> (Friday)
>>>Alas,
>>>moral progress has been so slow that almost the only moral problems to be
>>>even partially solved are those that can at least partially been turned into
>>>technological problems.
>>Not true, viz. cannibalism and slavery.
> Actually, it's my understanding that the demise of slavery was due to
> technological advances which made slavery economically unfeasible. The
> invention of the cotton gin, for example, made it only a matter of time
> here in the US before slavery died out. As far as cannibalism goes, I'd
> say that was more caused by Western culture steam-rolling over the
> cannibals.
> -- John --
Actually McCarthy's original comment presupposes that moral and technological
progress are comparable. It is that assumption that I disagree with. Ethics
and the attendant morality provide the context within which all activity, and
in particular technological progress, exists. Morality and technology are
not substitutes for one another and moral progress is not dependent on
technology nor vice versa. There is always technological progress attendant
to moral progress just because there is always technological progress.
--Charlie
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂15-Sep-85 0339 NEUMANN@SRI-CSLA.ARPA RISKS-1.13
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 15 Sep 85 03:39:28 PDT
Date: Sat 14 Sep 85 23:43:07-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.13
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-FORUM Digest Saturday, 14 Sep 1985 Volume 1 : Issue 13
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Risks in RISKS (Peter G. Neumann)
Preserving rights to Email messages (Larry Hunter)
Risk Comparisons (T. Tussing)
Risks history/philosophy (Nicholas Spies) [long but interesting]
[NOTE: RISKS-1.12 went out on Friday the 13th. Sorry for the double
mailing. MIC is full of pitfalls. I would like to believe that my macros
are now REALLY DEBUGGED, but I know better. However, things will run much
more smoothly on my end from now on, and I hope from yours also. Thanks for
your patience. PGN]
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Sat 14 Sep 85 23:18:42-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
To: RISKS@SRI-CSLA.ARPA
Subject: Risks in RISKS
The text of the message that follows this one is taken verbatim from the
HUMAN-NETS Digest (HUMAN-NETS@RUTGERS), 11 Sep 1985, Volume 8 : Issue 29, on
the topic of risks in EMAIL. That topic is of vital significance to the
RISKS Forum, for at least two reasons:
(1) You should recognize the risks that might be incurred by you in
submitting messages to this forum, and in sending on-line messages
in general.
(2) The free propagation of messages not copyrighted can itself lead
to significant risks to the contributor and to the RISKS Forum,
if those messages were false or libelous, or if they are altered.
In general, you and I must assume that any message on this forum may be
forwarded indefinitely and read by anyone, and could appear in print in all
sorts of strange places. (If something worthy of inclusion in the ACM
Software Engineering Notes is at all controversial, I ask for explicit
permission before publishing it.)
What is even RISKIER is that your message can be trivially altered along the
way as it traverses the network of networks, possibly drastically changing
your intended meaning. Use of check sums and crypto seals can reduce the
risk of undetected alteration, but does not solve the problem entirely.
Peter G. Neumann
(This message is not copyrighted.)
------------------------------
Subject: preserving rights to Email messages.
Date: Tue, 3 Sep 85 11:08:31 EDT
From: Larry Hunter <Hunter@YALE.ARPA>
Copyright-by: Larry Hunter, 1985
After consulting with several lawyer friends, the conclusion I
reach is that anything you send out over the nets is public
property -- ie, anyone can reproduce it verbatim, for profit
and the author has no right to control its use. There is,
however, a very simple way to preserve the author's rights to
control the use his messages are put to. The courts have
held that practically any clear attempt of an author to
preserve his/her rights to a written work are sufficient
to actually preserve them. No need to add the 'circled c'
to ASCII, just add a 'Copyright-by:' line to the header of your
local mailer and voila! your rights are preserved.
Larry
PS. I am not a lawyer and this is only my opinion - if you have
a vital interest in some related matter, talk to a real lawyer!
------------------------------
-------
Date: 13 Sep 85 13:27:12 PDT (Friday)
From: TTussing.es@Xerox.ARPA
Subject: Risk Comparisons
To: RISKS@SRI-CSL.ARPA
Someone sent me this and I thought the people on this mailing list might
be interested.
Excerpt from a pamphlet by Dow Chemical Corp, entitled Life is in the
Balance:
Dr. richard Wilson, who is professor of physics at Harvard, has devised
a mathematical formula that measures risks in terms of the minutes and
seconds of life lost. Taking the average person of 30 who has a
life-span in the United States of approximately 73 years, Wilson says
that statistical person cuts time from his life in the following ways:
Smoking one cigarette - minus 12 minutes
Drinking a diet soft drink - minus about 9 seconds
Driving without a seat belt - 6 seconds for each trip
Being an unmarried male - minus 1800 days
Being male rather than female - minus 2700 days
We can also view risks by figuring which risks are qeual. For example,
the following items all pose an equal risk of increasing the likelihood
of death by one chance in a million:
Drinking half a liter of wine
Spending three hours in a coal mine
Living two days in New York
Traveling six minutes by canoe
Riding 10 miles on a bicycle
Driving 300 miles in a car
Flying 1000 miles by jet
------------------------------
Date: 14 Sep 1985 01:06-EST
From: Nicholas.Spies@CMU-CS-H.ARPA
Subject: Risks history/philosophy
To: risks@sri-csl
This is definitely old news, but then again the facts behind the case have
only recently seen the light of day. In his recent biography "Alan Turing:
the enigma" (Simon & Schuster) Andrew Hodges reveals in some detail the
inner workings of the German Enigma encryption device (arguably a
"computer") which contributed (backhandedly) to the development of computers
as we know and love them today. (If you're interested in Turing, computers
or WWII history read it, if you haven't already.)
The portion of the book devoted to Turing's stint at Bletchley Park is
peppered with lost opportunities on the German side. Apparently with little
additional effort the Germans could have rendered the "Bletchley bombes"
completely useless. In fact the only reason the Germans were not careful was
their unswerving faith in the Enigma device. Even when there was ample
evidence pointing to a message-security problem the integrity of Enigma was
never seriously questioned by the Germans. There were, of course, countless
other factors, but the German faith in their technological answer was in
large measure responsible for their losing the U-boat war and very likely
the war itself.
Another anecdote, not related to computers (recounted in either "The Ultra
Secret", Winterbotham or "Bodyguard of Lies", A. Cave Brown, two other
excellent books on the secret war) gave one reason for the German atomic
bomb project not really getting off the ground. It seems that a German
professor of the old school was in charge of finding a material for
moderating a chain reaction (by absorbing neutrons). Graphite was tried but
failed which meant that deuterium (heavy water) was thought to be needed.
When it was suggested that the graphite might not be pure enough (which, as
it turned out, was the reason the test failed) the professor reacted with
rage that his authority was being questioned and he effectively derailed
German research in reactor design. (Later the plant for making heavy water
built in Norway was sabotaged by British agents which made a reactor
impossible which preventing the manufacture of fissile material.)
These examples suggest that excessive reliance on either technological
solutions or "authoritative opinion" may carry grave risks, albeit in these
cases for an evil regime. The question facing us is whether we (or the
Soviets, for that matter) have fallen into the same traps. I would say that
we (both) definitely have, for the means to power are now more than ever
technological (as opposed to political or diplomatic) and one or another
"expert" is routinely trotted out to "prove" the efficacy of this or that
technological scheme.
Indeed, how can it be otherwise? Hitler opened the Pandora's Box of applying
high-tech to warfare and it worked (at least until a higher-tech response
prevailed). After WWII a new era was born in which global political power no
longer rested on moral authority but on a command of the new applied
sciences and scientists. Engineers had provided political leaders with
instruments of war for centuries, but now scientists are looked upon as the
fountainhead of political power, by dictators, politicians and the people
alike. It may now be said truly that Knowledge is Power.
To some the risks of technology are the inevitable consequence of the
inexorable "progress" that technology itself represents. It seems to me that
this view places too great an emphasis on the growth of "technology" itself
at the expense of our ability to integrate it with human wants and needs.
It's almost to say that "technology" has a virtual life of its own that we
have no control over. This is manifestly untrue because "technology" is the
mere summation of the creative acts and compulsions of a great number of
people enamored of the idea of "technology". But if "technology" does have a
life of its own it must be based on a willing denial of responsibility on
the part of each member involved in furthering it, particularly when large
populations or the world are put at risk by introducing a new "technological
development". It seems, therefore, self-evident that morality and technology
are intimately interwoven.
In the largest sense, the risks of computers are the risks of having an
increasing number of computer experts that are in a position to tell people
what computers can be safely used for. Their expert opinions may be well
thought out or erroneous, as the case may be, but they are in fact the only
opinions that the public, financial institutions, military establishments or
politicians can depend on. The fact that any or all may place a value on
this expert information and act on it puts a heavy moral burden on the
providers of this information, whether they like it or not.
The only population that I have had direct contact with who have faced this
primal issue of the risks of technology are the Amish-Mennonites of Ontario;
I made a film about their 150th Anniversary in Canada. (I have also edited
films about the Amish in Lancaster Co., PA.) The trigger for the Amish was
rubber-tired wheels on carriages around the 1870's because this allowed the
young of courting age to "go to town" more easily, with a perceived
disruption of Amish life not far behind. To this "improvement" they said
"No". Subsequently, the Amish have taken great care to keep the increasing
technological developments surrounding them at bay, but not by pure
rejection. In short, they have evaluated the risks of adopting technologies.
For instance, gasoline engines are permitted for stationary use (and also on
horse-drawn wagons) for harvesting, threshing, bailing and for powering milk
refrigerators. There's no contradiction in using a valuable power source so
long as it isn't applied to providing the means for increased contact with
the outside world. Electricity is used if generated within the farm; and
public telephones may be used as well; as long as wires (i.e. connections)
to the outside world are avoided there is no reason to avoid using the
technology. The oddity of the Amish is based on common sense when their
objectives are known.
Although the Amish reaction to technology may strike many as merely "quaint"
they do show that it is possible to stop short the "inevitable" growth of
technology. (The Amish are renowned for their success in farming, which is
not the case for many others that have embraced modern technological ways.)
I am not advocating a general return to Amish ways (indeed this only makes
sense within the context of Amish values), but I will say that we all face a
similar confrontation with a technology that may do us great harm on many
fronts. Unfortunately we are prone to treat our own creations (be they
buildings, cars, chemicals or computers) as if they are as benevolent as the
products of 5 billion years of co-adaptive evolution. As increasingly
complex and interdependent as our creations become, the more they will
reveal themselves as ill-suited to the tasks they were meant to perform; it
only stands to reason because of the lack of a truly global feedback in the
design process. And also, how are we to judge the efficacy of our machines
if we have lost sight of the reason we have created them?
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂15-Sep-85 1200 CS.AVI@R20.UTEXAS.EDU PODS call for paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 15 Sep 85 11:58:45 PDT
Received: from R20.UTEXAS.EDU by su-aimvax.arpa with Sendmail; Sun, 15 Sep 85 11:58:46 pdt
Date: Sun 15 Sep 85 13:37:13-CDT
From: CS.AVI@R20.UTEXAS.EDU
Subject: PODS call for paper
To: nail@SU-AIMVAX.ARPA
PRELIMINARY CALL FOR PAPERS
(dates are tentative)
Fifth ACM SIGACT-SIGMOD Symposium on
PRINCIPLES OF DATABASE SYSTEMS
Cambridge, Massachusetts, March 24-26, 1986
The conference will cover new developments in both the theoretical and
practical aspects of database systems. Papers are solicited which
describe original and novel research about the theory, design,
specification, or implementation of database systems and query
languages.
Some suggested, although not exclusive, topics of interest are:
artifical intelligence for databases, concurrency control, database
design, database security, data models, data structures for databases,
dependency theory, distributed databases, file organization, logic for
databases, performance evaluation of database systems, query languages,
and schema design.
You are invited to submit nine (9) copies of a detailed abstract (not a
complete paper) to the program chairman:
Avi Silberschatz
Department of Computer Sciences
The University of Texas at Austin
Austin, TX 78712
(512) 471-4353
ARPANET: avi@utexas-20
Submissions will be evaluated on the basis of significance, originality,
and overall quality. Each abstract should 1) contain enough information
to enable the program committee to identify the main contribution of the
work; 2) explain the importance of the work - its novelty and its
practical or theoretical relevance to database management; and 3)
include comparisons with and references to relevant literature.
Abstracts should be no longer than ten double-spaced pages.
Program Committee:
Francois Bancilhon Christos Papadimitriou
Hector Garcia-Molina Ed Sciore
Jim Gray Avi Silberschatz
Alberto Mendelzon Moshe Vardi
Meral Ozsoyoglu
The deadline for submission of abstracts is October 11, 1985. Authors
will be notified of acceptance or rejection by December 6, 1985. The
accepted papers, typed on special forms, will be due at the above
address by January 10, 1986. All authors of accepted papers will be
expected to sign copyright release forms. Proceedings will be
distributed at the conference, and will be subsequently available for
purchase through ACM.
General Chairman: Local Arrangements Chairman:
Ashok K. Chandra Arvola Chan
IBM T.J. Watson Research Center Computer Corporation of America
P.O. Box 218 4 Cambridge Center
Yorktown Heights, NY 10598 Cambridge, MA 02142.
(914) 945-1752 (617) 492-8860
-------
∂15-Sep-85 1251 @MIT-MC.ARPA:7thSon@SCRC-STONY-BROOK.ARPA philosophy of science
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Sep 85 12:51:21 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 SEP 85 15:49:52 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 15 Sep 85 15:45-EDT
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 15 Sep 85 15:45:13 EDT
Received: from GOONEY.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 313944; Sun 15-Sep-85 15:41:30-EDT
Date: Sun, 15 Sep 85 15:45 EDT
From: Christopher Garrigues <7thSon@SCRC-STONY-BROOK.ARPA>
Subject: philosophy of science
To: phil-sci@MIT-MC.ARPA
cc: 7thSon@SCRC-STONY-BROOK.ARPA
Message-ID: <850915154511.4.7THSON@GOONEY.SCRC.Symbolics.COM>
I'd like to be added to the mailing list, please.
∂15-Sep-85 1307 @MIT-MC.ARPA:7thSon@SCRC-STONY-BROOK.ARPA philosophy of science
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Sep 85 13:06:55 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 SEP 85 15:55:26 EDT
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 15 Sep 85 15:50-EDT
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 15 Sep 85 15:49:10 EDT
Received: from GOONEY.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 313945; Sun 15-Sep-85 15:42:45-EDT
Date: Sun, 15 Sep 85 15:46 EDT
From: Christopher Garrigues <7thSon@SCRC-STONY-BROOK.ARPA>
Subject: philosophy of science
To: phil-sci@MIT-MC.ARPA
cc: 7thSon@SCRC-STONY-BROOK.ARPA
Supersedes: <850915154511.4.7THSON@GOONEY.SCRC.Symbolics.COM>
Message-ID: <850915154622.5.7THSON@GOONEY.SCRC.Symbolics.COM>
[whoops, sent to the wrong place. so sorry.]
∂16-Sep-85 0135 @SUMEX-AIM.ARPA:SAMUEL@SU-SUSHI.ARPA SIGBIG
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 01:35:24 PDT
Received: from SU-SUSHI.ARPA by SUMEX-AIM.ARPA with TCP; Mon 16 Sep 85 01:37:06-PDT
Return-Path: <@SU-SCORE.ARPA:welch@ames-vmsb.ARPA>
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Sat 14 Sep 85 13:07:39-PDT
Received: from su-aimvax.arpa by SU-SCORE.ARPA with TCP; Sat 14 Sep 85 13:05:14-PDT
Received: from ames-vmsb.ARPA by su-aimvax.arpa with TCP; Sat, 14 Sep 85 13:05:46 pdt
Date: 14 Sep 85 12:53:00 PST
From: welch@ames-vmsb.ARPA
Subject: SIGBIG
To: bayboards@diablo.ARPA
Reply-To: welch@ames-vmsb.ARPA
ReSent-Date: Mon 16 Sep 85 01:33:35-PDT
ReSent-From: Sam Hahn <Samuel@SU-SUSHI.ARPA>
ReSent-To: aap@SUMEX-AIM.ARPA
Reply-To: "DYMOND, KEN" <dymond@nbs-vms>
NBS PARALLEL COMPUTER BENCHMARK COLLECTION
The National Bureau of Standards, since its founding, has been
concerned with measurement, determining the precise values and metrics
for physical phenomena. The NBS has also made significant contri-
butions to metrology in numerous scientific and engineering
disciplines. In this tradition, the MPC (Measurement for Parallel
Computing) project at NBS is developing a set of metrics and measure-
ment techniques to characterize the performance of parallel processing
systems. As part of that effort, NBS is collecting benchmarks and code
kernels that represent a variety of applications which are candidates
for parallel processing. NBS solicits benchmark codes and kernels from
researchers and scientists. Programs which are computationally
intensive, I/O intensive, vectorizable or not and from non-numeric as
well as from numeric application areas are requested. Especially
welcome are programs which have been used to produce timing or speedup
data on parallel computers, whose measurement results have been or may
be published in the technical literature, and which are in some fairly
widely used and higher-level programming language such as FORTRAN,
"C", LISP, Ada, etc.
Contributions or inquiries should be directed to:
Measurement for Parallel Computing
Institute for Computer Sciences and Technology
Materials Building MS B364
National Bureau of Standards
Gaithersburg, MD 20899 USA
Telephone: 301-921-3274
ARPANET: MEASURE@NBS-VMS
------
------
∂16-Sep-85 1004 EMMA@SU-CSLI.ARPA CSLI talk
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 10:04:44 PDT
Date: Mon 16 Sep 85 10:03:05-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: CSLI talk
To: friends@SU-CSLI.ARPA
Tel: 497-3479
CSLI TALK
``Proto-Language''
C. B. Martin, Dept. of Philosophy, U. of Calgary
Friday, Sept. 20, 2:15, Ventura Conference Room
C. B. Martin has done a lot of important work in the philosophy of
religion, but also he wrote an extremely important paper on memory
with Max Deutscher, defending a causal theory of memory when this was
quite unfashionable. I think this paper played an important role in
setting the stage for causal theories of reference and action. Martin
is now doing work that sounds extremely interesting to me on the
semantics of non-verbal behavior. This following paragraph from his
paper gives a good indication of what it is about.
"The time is long overdue for the recognition of the semantic
import of non-verbal behaviour. Such behaviour is procedural
and projective for an outcome (that may or may not have
satisfaction). Though "true" and "false" may be reserved for
the verbal cases, there is a basic rightness and wrongness
about the non-verbal behavioural, procedural, projective
representations. Such behaviour is formed in inter-related
patterns strikingly and importantly analogous to that of
verbal language. I shall call such semantic non-verbal
behaviour "proto-language"."
--John Perry
-------
∂16-Sep-85 2057 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp%ucbernie@Berkeley
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 20:57:23 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Mon 16 Sep 85 20:52:39-PDT
Received: from UCB-VAX.ARPA by SU-SCORE.ARPA with TCP; Mon 16 Sep 85 20:52:38-PDT
Received: from ucbernie.ARPA by UCB-VAX.ARPA (4.24/5.6)
id AA06623; Mon, 16 Sep 85 14:36:05 pdt
Received: by ucbernie.ARPA (5.5/5.3)
id AA10496; Mon, 16 Sep 85 12:18:41 PDT
Date: Mon, 16 Sep 85 12:18:41 PDT
From: karp%ucbernie@Berkeley (Richard Karp)
Message-Id: <8509161918.AA10496@ucbernie.ARPA>
To: aflb.all@su-score.ARPA
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley 642-0143
SEMINAR ANNOUNCEMENTS
Thursday, September 19 4:00 MSRI Lecture Hall
Neil Immerman
Expressibility and First-Order Reductions
Tuesday, October 1 2:00 MSRI Lecture Hall
Christos Papadimitriou
How Easy is Local Search?
∂16-Sep-85 2307 NEUMANN@SRI-CSLA.ARPA RISKS-1.14
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 23:07:44 PDT
Date: Mon 16 Sep 85 21:54:25-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.14
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-FORUM Digest Monday, 16 Sep 1985 Volume 1 : Issue 14
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Pitfalls of a Fail-Safe Mail Protocol? (Peter G. Neumann)
Some Ruminations on an Ideal Defense System (Bob Estell)
SDI, feasibility is irrelevant (Gopal)
Note on contributions:
Let me remind you all that your contributions to RISKS should be objective,
nonpolitical, nonpersonal, and on the subject of the Forum. Some of you
have been drifting away from the charter. In fact, I rejected a message
from John McCarthy that seemed to violate the nonpolitical criterion,
although in hindsight that was probably a subjective decision. John
accepted that decision, but suggested that you could communicate
privately with him if you were curious. PGN
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Mon 16 Sep 85 20:25:57-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Pitfalls of a Fail-Safe Mail Protocol?
To: RISKS@SRI-CSLA.ARPA
After reading the case of the double posting of hundreds of millions of
dollars in RISKS-1.11, some of you apparently experienced the multiple
posting of RISKS-1.13 -- all original mailings time-stamped Sat 14 Sep 85
23:43:07-PDT, all complete, and all identical. Brint Cooper, for example,
received THREE identical copies at various time intervals.
Received: from brl-aos.arpa by TGR.BRL.ARPA id aa20274; 15 Sep 85 3:23 EDT
Received: from sri-csl.arpa by AOS.BRL.ARPA id a017885; 15 Sep 85 3:18 EDT
Received: from brl-aos.arpa by TGR.BRL.ARPA id a021160; 15 Sep 85 4:47 EDT
Received: from sri-csl.arpa by AOS.BRL.ARPA id a018065; 15 Sep 85 4:35 EDT
Received: from brl-aos.arpa by TGR.BRL.ARPA id a022055; 15 Sep 85 6:31 EDT
Received: from sri-csl.arpa by AOS.BRL.ARPA id a018257; 15 Sep 85 6:17 EDT
The new ARPANET message protocols are supposed to be fail-safe (never losing
a message, retrying sensibly after a failure, and eventually returning
undeliverable mail with a NAK), network-efficient (transmitting single
copies to each host and letting that host redistribute), and reliable (never
garbling a message) -- although they cannot guarantee message authenticity
in the presence of tampering.
After consulting with my Foonly-TOPS-20 gurus (Geoff Goodfellow, Mark
Lotter, and Dwight Hare), we discovered that just after I mailed RISKS-1.13
late Saturday night, Foonly's David Poole brought our system down and up
(several times?) after midnight PDT for installation of a 100% memory
increment. Each time he brought it back up, the mailer seems to have
restarted sending some of the previously queued messages -- how many I do
not know. It is NOT SUPPOSED TO DO THAT, but that is the most plausible
explanation at the moment. If you again receive multiple copies, please
remail them back in their entirety to Geoff@SRI-CSL (and we'll hope that you
don't blow his mailbox). Geoff insists the protocol is sound, so let's let
him in on the glitch-hunt! Meanwhile, we'll follow a bunch of possibilities.
Analogous to the time-out problem described in RISKS-1.11 causing
double-posting of millions of dollars, a similar problem can arise in the
ARPANET if a receiving host does not acknowledge soon enough, causing a
time-out and retry -- even though the message was successfully received.
This has been known to happen, but probably not repeatedly, as in the
RISKS-1.13 duplication.
Sorry for the inconvenience. We will take several measures to try to
prevent a recurrence, but if there is a real bug in the protocols or in
their implementation, then we will just have to slug it out until it is found.
Peter
------------------------------
Date: Mon, 16 Sep 85 12:21:52 PDT
From: estell@NWC-143B
Subject: Some Ruminations on an Ideal Defense System
To: risks@sri-csl.arpa
SOME RUMINATIONS on AN IDEAL DEFENSE SYSTEM 16 SEP 85 [RGE]
WHAT ARE THE CHARACTERISTICS OF AN IDEAL DEFENSE SYSTEM?
(Never mind that it does NOT exist - and likely will not in my lifetime.)
1. Useful ONLY on the defensive; incapable of use as an offensive weapon.
2. Effectiveness: 100%.
3. Reliability: 100%.
4. Cost: Cheap. So economical to manufacture and deploy that everyone who
needs one (or two) could have it.
5. Simple to use; requires no training; requires no "technology base."
6. Easy to maintain; essentially never wears out, or breaks.
7. Side effects of use or possession: None.
EXAMPLES OF SYSTEMS THAT DO NOT MEET THE IDEAL REQUIREMENTS.
1. Planes, ships, tanks, guns, and bombs - of any size.
2. Chemicals, gas, germs, etc.
EXAMPLES OF SYSTEMS THAT MIGHT - or might not - SUFFICE.
(They clearly won't satisfy all the above requirements.)
1. SDI - whatever that turns out to be, a few billion $ from now.
2. MX - NOT the expensive "new" systems recently voted, but simple
modifications of older, reliable, affordable technology. The key
is the nature of the modifications. This isn't the place to say more.
WHY THIS PROPOSAL IS WORTH LOOKING AT.
1. The technology is mature, affordable, and operational.
2. The super-powers can USE this proposal, this year, or next.
Not just the USA and the USSR; but a few other nations, too.
3. The "trouble makers" who haven't yet demonstrated the maturity to
abstain from rash use of a "doomsday" device can't use this idea.
4. It saves money; and buys time - precious time, in which we can
learn to trust each other, and to respect our differences -
accepting the fact that "... east is east and west is west,
and never the twain shall meet ..." [Kipling]
WHY THIS PROPOSAL WILL BE RESISTED - perhaps EVEN DISCARDED.
1. Not many vendors will win multi-year, multi-billion contracts to
develop and manufacture these systems. That has largely been done.
2. Not many career officers and bureaucrats will get multiple promotions
for the development and deployment of these systems; again, that's done.
SOME CONFESSIONS ABOUT MY MOTIVES.
I believe that Americans and Russians, Christians, Moslems, Jews, Buddhists,
atheists, agnostics, capitalists, communists, socialists, pacifists, hawks,
doves, owls, and others CAN live together; not in "harmony" - but in some
civility, with respect. My belief is based on two facts:
1. The lion and the lamb may never lie down together, but the lion and the
antelope presently share the veldt; blood is shed, but genocide does not
occur. It's elsewhere called the "balance of nature." There is even some
evidence that the process improves the strain of antelope - and lion.
2. I cannot accept gross demeaning judgments made about a people who produce
some of the world's really great classical music. Tchaikovsky, Borodin,
and others have composed the best - in my opinion. I believe that the
Russians love their country, their families, their music, and the Almighty
- by whatever name He may be called - just as we do; and, like us, they fear
(or at least don't enjoy the thought of) death, starvation, disease, hatred,
suspicion, etc. Why are they so "defensive" - an enigma wrapped in a
mystery, surrounded by a riddle? (or whatever exact phrase Churchill
turned in '48) Their land was invaded twice in the lifetime of their most
recent leaders - men born before WWI. The losses of life were catastrophic;
almost 25% of the adult male population died each time - though the WWI
figures get blurred with the totals from their own revolution. And those
weren't the first times; Napoleon did it in the 19th century, and the
Mongols did it earlier. That plus the oppressive cold of a lingering
winter give them a somewhat different world view.
But in a quarter century, they, like us, have NOT pushed the button. That
speaks well for their responsibility.
Our REAL problem - in the USA and the USSR and the third world - indeed in the
entire world - is NOT communists, not Arabs, not any organized government, nor
religion; it is terrorists - criminals; men of desperation, who when armed will
extract their needs by violence, and damn the consequences. We have more than
our share of such trouble-makers; they have attacked many of our prominent
citizens recently: John and Robert Kennedy, Martin Luther King, Jr., Ronald
Reagan, Patty Hearst, and Malcolm X are examples easily remembered.
If some of the money spent now on weapons can be re-invested in research in
medicine, in electronics for space exploration, in agriculture, etc. there will
be no loss of income for the scientists and business men now supplying the
Pentagon. True, many of them will have to adapt; but then, they do that now.
The arms of WWII just don't sell today. A Technology Base that supports
sophisticated weapons to kill people can adapt to kill viruses; to guide
rockets to the distant galaxies, instead of missiles to distant cities; to
detect bombs of terrorists, instead of bombs of military commandos. I will
have to be one of those who adapt; my employer, the Naval Weapons Center, must
adapt too. We are intellectually capable of doing that.
RGE≠
------------------------------
Date: 16 Sep 85 11:09:56 PDT (Monday)
Subject: Re: SDI, feasibility is irrelevant (Response to McCarthy)
To: RISKS@SRI-CSL.ARPA
From: Gopal <Gopal.es@Xerox.ARPA>
Your analogy to SDI of a duelling gunman putting on a bullet-proof vest
seems slightly flawed, but your overall point is well taken:
The vest is far from being bullet proof...and the vest dose not
exist yet. The gunman has just thought about making one, after many
fruitless years of holding guns at each other. It is likely that he may not
succeed in making a vest that stops any bullet. The other gunman knows this.
But IF he should succeed, THEN, the status quo is broken immediately:
the very fact of possession of a bullet proof vest indicates that he can
turn the outcome decisively in his favor. This clearly will be perceived
as an act of hostility by the worst-case-strategists at the Kremlin. If
I were them, I would not sit by idly, twiddling my thumb: I would launch.
Sure, the gunman trying to make the vest has promised to give one to
the other gunman also, so there would be no hostility. But, WHEN he has
one, he would not give it away. The strategists do not plan on the basis
of goodwill. They would wait until a 'crisis' develops that forces them
to make a hard choice: share SDI or die.
Would they get rid of the guns, once each one has a vest to stop
bullets? Not likely. We all know that when he was the only gunslinger in
town, he opted to keep that gun in case the other guy gets hold of
one...but now he can't get rid of his gun BECAUSE the other guy has one
too! If there is enough goodwill to get rid of the guns with vests, it
should be even more feasible to get rid of them now, without having to
incur the cost of the vests. Such goodwill simply does not exist while
there is also fear.
If SDI should succeed, even partially, (that is, if the monkey should
reach the moon, at least partially, by climbing the tree) then the only
option would be to share SDI with the other guy. Even after sharing
SDI, we are still bound by fear, of a different kind: what if one
develops a way to take out the other guy's SDI somehow by first strike
and tip the scales in his favour? Another president will come along to fund
this project, because the other side "already started on it and we don't
want to compromise national security". The other side, of course, needs
no excuses like this. And, history will repeat...and repeat.
SDI does not solve the basic nature of the conflict in purpose that
national leaders must exhibit: They must get rid of the guns to make
peace and rid their people of fear, and they must protect national
security. These are clearly not compatible goals in a world of hostile
Governments. The Governments of the world hold the people hostage to
fear and insecurity, much like a handful of gun-slinging gangsters
holding a vast majority hostage to fear of crime.
I admit that it is much easier to shoot down an idea (like SDI) than to
offer an easy alternative in a complex problem like this. But let this
not be a reason to adopt a faulty approach like SDI.
Well, 'nuff ramblin' on SDI. By the way, October issue of Science '85
magazine has a cover story on "RISKS: How it is perceived" and I thought
it was quite thought-provoking and may help us understand how
SDI-like-risk is perceived by the people. I highly recommend reading it.
Gopal
[This message is marginally on the subject -- assuming the original
message was. I'm not sure whether it sharpens or blunts the
would-be analogy, but let's blow the whistle on the bullet-proof
vest at this point. Thanks. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂16-Sep-85 2355 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #15
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 23:55:10 PDT
Date: 16 Sep 85 2342-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #15
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Tuesday, 17 Sep 1985 Volume 1 : Issue 15
Today's Topics:
Quickly computing quarks
NBS Parallel Computer Benchmark Collection
----------------------------------------------------------------------
[From HUMAN-NETS Digest V8 #27]
Date: 19-Aug-85 10:20 PDT
From: William Daul / McDonnell-Douglas / APD-ASD
From: <WBD.TYM@OFFICE-2.ARPA>
Subject: Quickly Computing Quarks (Science News, VOL. 128)
To: physics@sri-unix.arpa
...news of at least one IBM research effort in high-speed computing
surfaced at last month's National Computer Conference in Chicago. A
team of physicists will soon take over a specially built computer
designed to solve a single physics problem. According to an IBM
official, this computer is supposed to take less than a year to solve
a problem that would take a CRAY-1 supercomputer more than 300 years
to do.
The IBM machine, developed at the Thomas J. Watson Research Center in
Yorktown Heights, N.Y., consists of an array of 576 processors, each
one capable of 20 million "floating point" operations per second
(equivalent to multiplying two decimal numbers 20 million times). In
contrast, a typical personal computer performs 1,000 or so such
operations per second. When all the processors are working in
parallel, each one handling a small part of a computation, the IBM
computer can handle more than 10 billion floating point operations per
second.
The machine will be used to calculate the mass of a proton from "first
principles," applying quantum chromodynamics theory. This year-long
exercise should give physicists some clues as to the validity of
their concepts about quarks and gluons. Once this project is over,
the machine could be used for other purposes, says IBM's George Paul.
And the computer's design team is already thinking about how to extend
the ideas they developed for the original machine.
------------------------------
[Forwarded by Sam Hahn <Samuel@SU-SUSHI.ARPA>]
Date: Saturday, 14 September 1985 13:53-PDT
From: welch at ames-vmsb.ARPA
Reply-To: welch at ames-vmsb.ARPA
To: bayboards at diablo.ARPA
Re: SIGBIG
Reply-To: "DYMOND, KEN" <dymond@nbs-vms>
NBS PARALLEL COMPUTER BENCHMARK COLLECTION
The National Bureau of Standards, since its founding, has been
concerned with measurement, determining the precise values and metrics
for physical phenomena. The NBS has also made significant
contributions to metrology in numerous scientific and engineering
disciplines. In this tradition, the MPC (Measurement for Parallel
Computing) project at NBS is developing a set of metrics and
measurement techniques to characterize the performance of parallel
processing systems. As part of that effort, NBS is collecting
benchmarks and code kernels that represent a variety of applications
which are candidates for parallel processing. NBS solicits benchmark
codes and kernels from researchers and scientists. Programs which are
computationally intensive, I/O intensive, vectorizable or not and from
non-numeric as well as from numeric application areas are requested.
Especially welcome are programs which have been used to produce timing
or speedup data on parallel computers, whose measurement results have
been or may be published in the technical literature, and which are in
some fairly widely used and higher-level programming language such as
FORTRAN, "C", LISP, Ada, etc.
Contributions or inquiries should be directed to:
Measurement for Parallel Computing
Institute for Computer Sciences and Technology
Materials Building MS B364
National Bureau of Standards
Gaithersburg, MD 20899 USA
Telephone: 301-921-3274
ARPANET: MEASURE@NBS-VMS
------------------------------
End of PARSYM Digest
********************
∂17-Sep-85 0027 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #16
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 17 Sep 85 00:27:53 PDT
Date: 16 Sep 85 2359-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #16
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Tuesday, 17 Sep 1985 Volume 1 : Issue 16
Today's Topics:
PARSYM Special Issue: IJCAI-85 Abstracts
----------------------------------------------------------------------
[This special issue of PARSYM consists of abstracts of papers
presented at IJCAI-85, the Ninth International Joint Conference on
Artificial Intelligence, 18-23 August 1985. The abstracts included
are from papers particularly relevant to parallel symbolic computing.
The papers are published in the Proceedings, available from Morgan
Kaufmann Publishers, 95 First Street, Los Altos, California 94022.
-- BD]
The Intelligent Channel: A Scheme for Result Sharing in Logic Programs
Simon Kasif and Jack Minker
University of Maryland
The separation of logic and control in logic programs allows the
programmer to write programs whose execution is determined by the
interpreter. This characteristic of logic programs spurred research
towards diversifying the means for controlling the execution of logic
programs, and towards understanding and exploring the value of
parallelism in logic programming. Much of these efforts belong to the
study of AND/OR-parallelism, i.e., parallel execution of
conjunctive/disjunctive goals respectively.
A brute force approach to AND/OR-parallelism, i.e., executing every
possible subgoal in a conjunctive goal, has two major drawbacks:
combinatorial explosion of processes and the need for many active
binding environments. The latter arises due to the interaction of
shared variables in conjunctive goals.
We propose a scheme to alleviate the above difficulties. For
simplicity, we demonstrate our approach with examples where atoms
share a single variable. The approach is applicable to Horn-clause
logic programs.
------------------------------
The Architecture of the FAIM-1 Symbolic Multiprocessing System
A. L. Davis
S. V. Robison
Schlumberger Palo Alto Research
The FAIM-1 is an ultra-concurrent symbolic multiprocessor which
attempts to significantly improve the performance of AI systems. The
system includes a language in which concurrent AI applications programs
can be written, a machine which provides direct hardware support for
the language, and a resource allocation mechanism which maps programs
onto the machine in order to exploit the program's concurrency in an
efficient manner at run-time. The paper provides a brief synopsis of
the nature of the language and resource allocation mechanism, but is
primarily concerned with the description of the physical architecture
of the machine. The architecture is consistent with high-performance
VLSI implementation and packaging technology, and is easily extended
to include arbitrary numbers of processors.
------------------------------
A Variable Supply Model for Distributing Deductions
Vineet Singh
Michael R. Genesereth
Stanford University
Multiple processors can be used to speed up a backward-chaining
deduction by distributing or-parallel deductions. However, the actual
speedup obtained is strongly dependent on the amount of communication
required for the task allocation strategy. A variable supply model
(VSM) is presented for multiple processors with replicated databases on
a broadcast network. The term "model" refers to the set of procedures
and messages required to perform the computation. VSM allows an
infinite class of strategies with varying amounts of communication.
The utility of VSM lies in the easy and powerful way it provides for
selecting a strategy that works satisfactorily given certain
communication constraints. All strategies in VSM use a dynamic task
supply protocol (ESP) that works better than other supply protocols
described in the literature.
------------------------------
Parallelism in AI Programs
Dennis F. Kibler
University of California at Irvine
John Conery
University of Oregon
A folk theorem is developing which suggests that parallel solution of
AI programs will not afford a speedup of more than one order of
magnitude. We critically review this folk theorem by analyzing some
of the problems used to "prove" it, and then cite work that provides
examples of better than one order of magnitude improvement for these
problems. We examine two representative AI algorithms where
parallelism would achieve speedups of two orders of magnitude with a
reasonable number of processors.
------------------------------
Recognition Algorithms for the Connection Machine
Anita M. Flynn
John G. Harris
MIT
This paper describes an object recognition algorithm both on a
sequential machine and on a SIMD parallel processor such as the MIT
Connection Machine. The parallel version is shown to run three to
four orders of magnitude faster than the sequential version.
------------------------------
NON-VON's Applicability to Three AI Task Areas
David Elliot Shaw
Columbia University
NON-VON is a massively parallel machine constructed using custom VLSI
chips, each containing a number of simple processing elements. A
preliminary prototype is now operational at Columbia University. The
machine is intended to provide highly efficient support for a wide
range of artificial intelligence and other symbolic applications.
This paper briefly describes the current version of the NON-VON
machine and presents evidence for its applicability to the execution
of OPS5 production systems, a number of low- and intermediate-level
computer vision tasks, and certain "difficult" relational algebraic
operations relevant to knowledge base management. Analytic and
simulation results are presented for a number of algorithms. The data
suggest that NON-VON could provide a performance improvement of as
much as two to three orders of magnitude over a conventional
sequential machine for a wide range of AI tasks.
------------------------------
End of PARSYM Digest
********************
∂17-Sep-85 0911 ullman@su-aimvax.arpa meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Sep 85 09:11:30 PDT
Received: by su-aimvax.arpa with Sendmail; Tue, 17 Sep 85 09:11:27 pdt
Date: Tue, 17 Sep 85 09:11:27 pdt
From: Jeff Ullman <ullman@diablo>
Subject: meeting
To: nail@diablo
We'll meet at 11AM in 301 on Wednesday, as usual.
NExt Wednesday, the 25th, is Yom Kippur, and I will not
be here. You folks can meet by yourselves if you wish,
but I suspect we should just cancel the meeting.
Anyway, the topic for this week will be further progress
on deciding whether a logic program is in NC or is P-complete.
Allen and I will hold forth.
∂17-Sep-85 0918 ullman@su-aimvax.arpa paper recieved
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Sep 85 09:18:09 PDT
Received: by su-aimvax.arpa with Sendmail; Tue, 17 Sep 85 09:17:58 pdt
Date: Tue, 17 Sep 85 09:17:58 pdt
From: Jeff Ullman <ullman@diablo>
Subject: paper recieved
To: nail@diablo, paco@diablo
Does anybody want to see: "Parallel Algorithms for Term MAtching""
by Dwork, Kanellakis, and Stockmeyer?
It improves the number of processors needed from n↑5 to n↑3,
while still running in polylog time.
---Jeff Ullman
∂17-Sep-85 0922 RICHARDSON@SU-SCORE.ARPA Sr. Faculty Meeting September 24
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 17 Sep 85 09:22:20 PDT
Date: Tue 17 Sep 85 09:13:21-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Sr. Faculty Meeting September 24
To: tenured@SU-SCORE.ARPA
Message-ID: <12143997993.13.RICHARDSON@SU-SCORE.ARPA>
There will be a sr. faculty meeting on September 24, 1985 following the
general faculty meeting scheduled at 2:30 in Conference Room 146 of
Margaret Jacks Hall. Should you have any agenda items that you would like
to be included, please indicate to me.
Thanks,
Anne Richardson
-------
∂17-Sep-85 1140 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA PLANLUNCH REMINDER -- Wednesday, 11AM
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 17 Sep 85 11:38:42 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 17 Sep 85 11:29:52-PDT
Date: Tue 17 Sep 85 11:25:54-PDT
From: LANSKY@SRI-AI.ARPA
Subject: PLANLUNCH REMINDER -- Wednesday, 11AM
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, rsimmons@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
vanLehn@XEROX.ARPA, araya@XEROX.ARPA, frayman@XEROX.ARPA,
suchman@XEROX.ARPA, weld@XEROX.ARPA, mittal@XEROX.ARPA, dekleer@XEROX.ARPA
SCRUFFY PLANNING
David Wilkins
SRI International AI Center
11:00 AM, WEDNESDAY, September 18
SRI International, Building E, Room EK242
Most of the talks in the planlunch series have been about "neat"
research. While neat researchers know they have a more
expressive formalism than do planners like SIPE, they have rarely
sat in front of a machine and watched their systems be overwhelmed
by the computational loads even simple representations can impose.
I'll defend scruffy planning (not to replace but to supplement neat planning),
show how SIPE represents a simple 6-room indoor world for Flakey, show
its solutions and use of computation, describe the kind of hacks needed to
make things run fast, describe pitfalls, and other scruffy stuff like that.
Only a small amount of time will be spent explaining SIPE, depending on
audience's desire.
-------
-------
∂17-Sep-85 1523 ullman@su-aimvax.arpa papers received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Sep 85 15:23:12 PDT
Received: by su-aimvax.arpa with Sendmail; Tue, 17 Sep 85 15:22:02 pdt
Date: Tue, 17 Sep 85 15:22:02 pdt
From: Jeff Ullman <ullman@diablo>
Subject: papers received
To: nail@diablo
"Termination of Rewriting" by Nachum Dershowitz.
A survey about well-founded ordering proofs.
"Logic Programming cum Applicative Programming"
Dershowitz and Plaisted.
∂17-Sep-85 1622 MARJORIE@SU-CSLI.ARPA Books
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 17 Sep 85 16:22:34 PDT
Date: Tue 17 Sep 85 16:16:21-PDT
From: Marjorie Maxwell <MARJORIE@SU-CSLI.ARPA>
Subject: Books
To: folks@SU-CSLI.ARPA
We are missing some books from the consultants office - if anyone has
borrowed them and forgotten to return them please let us know. They are
2 Scribe Users Manuals
1 Revised Maclisp Manual (Pitman, Kent)
1 A Practical Guide to Unix (Sobell, Mark)
1 Artificial Intelligence Programming (Charniak, Riesbeck)
Thanks,
Marj
-------
∂17-Sep-85 2008 PIERRE@SU-CSLI.ARPA Books
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 17 Sep 85 20:08:47 PDT
Date: 17 Sep 1985 20:03 PDT (Tue)
Message-ID: <PIERRE.12144116343.BABYL@SU-CSLI.ARPA>
From: Peter King <PIERRE@SU-CSLI.ARPA>
To: Marjorie Maxwell <MARJORIE@SU-CSLI.ARPA>
Cc: folks@SU-CSLI.ARPA
Subject: Books
In-reply-to: Msg of 17 Sep 1985 16:16-PDT from Marjorie Maxwell <MARJORIE>
I have one of the Scribe Manuals.
Peter
∂18-Sep-85 0133 ACUFF@SUMEX-AIM.ARPA Explorer Mailing Lists
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 01:32:55 PDT
Date: Wed 18 Sep 85 01:34:22-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Explorer Mailing Lists
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12144176583.32.ACUFF@SUMEX-AIM.ARPA>
In order to facilitate information exchange among projects using TI
Explorers, two mailing lists are being created. INFO-TI-EXPLORER will
be used for general information distribution, such as operational
questions, or announcing new generally available packages or tools.
BUG-TI-EXPLORER will be used to report problems with Explorer
software, as well as fixes. Requests to be added to or deleted from
these lists should be sent to INFO-TI-EXPLORER-REQUEST or
BUG-TI-EXPLORER-REQUEST, respectively. All addresses are at
SUMEX-AIM.ARPA. These lists signify no commitment from Texas
Instruments. Indeed, there is no guarantee that TI representatives
will read the lists. The idea of the lists is to provide
communication among the users of Explorers. Archives will be kept on
SUMEX-AIM.ARPA in BBoard:*-TI-Explorer.txt, which can be with BBoard.
-- Rich
-------
∂18-Sep-85 1536 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 15:29:25 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Wed 18 Sep 85 15:21:22-PDT
Date: Wed 18 Sep 85 15:19:44-PDT
From: LANSKY@SRI-AI.ARPA
Subject: Next Monday's PLANLUNCH
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, rsimmons@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
vanlehn@XEROX.ARPA, araya@XEROX.ARPA, frayman@XEROX.ARPA,
suchman@XEROX.ARPA, weld@XEROX.ARPA, mittal@XEROX.ARPA, dekleer@XEROX.ARPA,
trigg@XEROX.ARPA
THE SKY IS A BLUE COLOR
Marcel Schoppers
SRI International AI Center
11:00 AM, MONDAY, September 23
SRI International, Building E, Room EJ228 (new conference room)
I present a representation which will allow us to encode and
access much of the information contained in simple descriptive
statements. "The sky is a blue color" entails that blue is a
color, that the sky has a color, that the sky is blue, that the
sky is visible, and that the sky is located both spatially and
temporally. These generalizations are so trivial that they border
on presuppositions, and they have consequently been taken for
granted in semantic nets and frames. Making such information
explicit greatly increases the density and usefulness of stored
knowledge. One interesting application is to disambiguate an
adjective/predicate to suit a given noun/extension.
My representation is parsimonious, having O(three) primitive con-
structs (link types); is highly irredundant, since blue(sky) and
color(blue) reference the same blue; and is static, being inten-
ded to formalize and implement "massively parallel" deterministic
connectionist question-answering systems. Predicates, relations,
and simple forms of quantification all emerge as by-products of
function applicability and set inclusion. Viewed as a logic the
representation is potentially O(w), intensional and inconsistent.
The talk will touch on issues in philosophy of logic and linguistics.
I will especially appreciate constructive criticism in those areas,
as I am a novice there.
-------
∂18-Sep-85 1615 SUSI@SU-CSLI.ARPA opportunity to share
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 16:15:07 PDT
Date: Wed 18 Sep 85 16:10:00-PDT
From: Susi Parker <SUSI@SU-CSLI.ARPA>
Subject: opportunity to share
To: FOLKS@SU-CSLI.ARPA
There will be a slide projector available in the Ventura Hall
Conference Room if you wish to use it (and the room, when available)
do so~~~offer expires "this" Friday
-------
∂18-Sep-85 2111 davies%ucbcogsci@Berkeley UCB Cognitive Science Seminar, Sept. 24, 1985
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 21:11:27 PDT
Received: from ucbcogsci.ARPA by UCB-VAX.ARPA (4.24/5.6)
id AA00948; Wed, 18 Sep 85 12:19:42 pdt
Received: by ucbcogsci.ARPA (5.5/5.7)
id AA07592; Wed, 18 Sep 85 11:12:07 PDT
Date: Wed, 18 Sep 85 11:12:07 PDT
From: davies%ucbcogsci@Berkeley (Catherine Davies)
Message-Id: <8509181812.AA07592@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley
Subject: UCB Cognitive Science Seminar, Sept. 24, 1985
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, September 24, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Peter Pirolli, School of Education,
UC Berkeley
TITLE: ``A Cognitive Model and Intelligent Computer
Tutor for Programming Recursion''
Recursion is typically a novel concept for programming stu-
dents that causes them considerable grief and difficulty.
Thus, the study of how people learn to program recursive pro-
grams provides a useful domain for addressing the psychologi-
cal issue of how fundamentally new knowledge is acquired as
well as the instructional issue of how to teach a difficult
programming concept. I will present a production system model
that addresses expert and novice problem-solving, problem-
solving by analogy, and skill acquisition in programming
recursive functions. This research served as the basis for
the development of recursion lessons in an intelligent com-
puter tutor for programming LISP. Specifically, a simulation
model of ``ideal'' and ``buggy'' novice problem-solving was con-
structed for coding recursion. Using this model, the LISP
tutor provides instruction, hints, and feedback in the context
of programming. The LISP tutor also maintains a model of the
skill development of individual students. Evaluations show
that the LISP tutor is more effective in teaching introductory
LISP programming than good classroom instruction and
approaches the effectiveness of human tutors.
---------------------------------------------------------------------
UPCOMING TALKS
Oct 1: David Rumelhart, Cognitive Science, UCSD
Oct 8: Terry Winograd, Computer Science, Stanford
Oct 15: Ron Kaplan, Xerox PARC
Oct 22: Lotfi Zadeh, Computer Science, UCB
Oct 29: Mardi Horowitz, Psychiatry, UCSF
Nov 5: TBA
Nov 12: TBA
Nov 19: Richard Alterman, Computer Science, UCB
Nov 26: Eve Clark, Linguistics, Stanford
∂18-Sep-85 2112 @SU-CSLI.ARPA:davies%ucbcogsci@Berkeley UCB Cognitive Science Seminar, Sept. 24, 1985
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 21:12:43 PDT
Received: from UCB-VAX.ARPA by SU-CSLI.ARPA with TCP; Wed 18 Sep 85 21:08:54-PDT
Received: from ucbcogsci.ARPA by UCB-VAX.ARPA (4.24/5.6)
id AA00948; Wed, 18 Sep 85 12:19:42 pdt
Received: by ucbcogsci.ARPA (5.5/5.7)
id AA07592; Wed, 18 Sep 85 11:12:07 PDT
Date: Wed, 18 Sep 85 11:12:07 PDT
From: davies%ucbcogsci@Berkeley (Catherine Davies)
Message-Id: <8509181812.AA07592@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley
Subject: UCB Cognitive Science Seminar, Sept. 24, 1985
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, September 24, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Peter Pirolli, School of Education,
UC Berkeley
TITLE: ``A Cognitive Model and Intelligent Computer
Tutor for Programming Recursion''
Recursion is typically a novel concept for programming stu-
dents that causes them considerable grief and difficulty.
Thus, the study of how people learn to program recursive pro-
grams provides a useful domain for addressing the psychologi-
cal issue of how fundamentally new knowledge is acquired as
well as the instructional issue of how to teach a difficult
programming concept. I will present a production system model
that addresses expert and novice problem-solving, problem-
solving by analogy, and skill acquisition in programming
recursive functions. This research served as the basis for
the development of recursion lessons in an intelligent com-
puter tutor for programming LISP. Specifically, a simulation
model of ``ideal'' and ``buggy'' novice problem-solving was con-
structed for coding recursion. Using this model, the LISP
tutor provides instruction, hints, and feedback in the context
of programming. The LISP tutor also maintains a model of the
skill development of individual students. Evaluations show
that the LISP tutor is more effective in teaching introductory
LISP programming than good classroom instruction and
approaches the effectiveness of human tutors.
---------------------------------------------------------------------
UPCOMING TALKS
Oct 1: David Rumelhart, Cognitive Science, UCSD
Oct 8: Terry Winograd, Computer Science, Stanford
Oct 15: Ron Kaplan, Xerox PARC
Oct 22: Lotfi Zadeh, Computer Science, UCB
Oct 29: Mardi Horowitz, Psychiatry, UCSF
Nov 5: TBA
Nov 12: TBA
Nov 19: Richard Alterman, Computer Science, UCB
Nov 26: Eve Clark, Linguistics, Stanford
∂19-Sep-85 0850 EMMA@SU-CSLI.ARPA Newsletter September 19, No. 46
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Sep 85 08:50:45 PDT
Date: Thu 19 Sep 85 08:14:26-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter September 19, No. 46
To: friends@SU-CSLI.ARPA
Tel: 497-3479
***** Sorry for the delay but SU-CSLI crashed just as I was about to send
the Newsletter yesterday.******
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
September 19, 1985 Stanford Vol. 2, No. 46
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, September 19, 1985
12 noon TINLunch
Ventura Hall ``Some Remarks on the Relationship of Mind to
Conference Room Meaning and Language''
Discussion led by Daniel Isaacson, Oxford University
2:15 p.m. CSLI Talk
Ventura Hall No talk this week
Seminar Room
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, September 26, 1985
12 noon TINLunch
Ventura Hall ``The Concept of Supervenience''
Conference Room Discussion led by Carol Cleland
(Abstract on page 1)
2:15 p.m. CSLI Talk
Ventura Hall No talk this week
Seminar Room
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S TINLUNCH
``The Concept of Supervenience''
Traditionally the notion of supervenience has been associated with
moral philosophy (particularly, value theory). In recent years,
however, there has been a growing interest among philosophers in
developing a concept of supervenience that could be employed in the
analysis of certain problematic relations, e.g., between the mental
and the physical, between macrostates of the world and microstates of
the world.
The appeal of the concept of supervenience for philosophers
involves several factors. First, supervenience is a weaker relation
that the relation of so-called ``reducibility.'' While reducibility
is traditionally taken to involve the presence of bi-conditional
correlations between every ``reduced'' property and every ``reducing''
property, supervenience does not. Yet, like reducibility,
supervenience appears to be able to provide us with a robust notion of
the determination of one family of properties by another.
The question is: Can supervenience live up to its promise?
--Carol Cleland
!
Page 2 CSLI Newsletter September 19, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
TALK
``Proto-Language''
Professor C. B. Martin, Dept. of Philosophy, U. of Calgary
Friday, September 20, 2:15, Ventura Conference Room
C. B. Martin has done a lot of important work in the philosophy of
religion, but also he wrote an extremely important paper on memory
with Max Deutscher, defending a causal theory of memory when this was
quite unfashionable. I think this paper played an important role in
setting the stage for causal theories of reference and action. Martin
is now doing work that sounds extremely interesting to me on the
semantics of non-verbal behavior. This following paragraph from his
paper gives a good indication of what it is about.
``The time is long overdue for the recognition of the semantic
import of non-verbal behaviour. Such behaviour is procedural
and projective for an outcome (that may or may not have
satisfaction). Though ``true'' and ``false'' may be reserved
for the verbal cases, there is a basic rightness and wrongness
about the non-verbal behavioural, procedural, projective
representations. Such behaviour is formed in inter-related
patterns strikingly and importantly analogous to that of
verbal language. I shall call such semantic non-verbal
behaviour ``proto-language''.'' --John Perry
←←←←←←←←←←←←
TALK
``Crossing the Rubicon: From a Physics of Dead Coordinate Spaces
to a Physics of Living Coordinate Spaces''
Dr. Peter Kugler, The Crump Institute for Medical Engineering, UCLA
Monday, September 23, 1985, 2:15pm, Ventura Hall
This talk will be about self-organizing systems that involve
low-energy (nonforce) coupling and the nature of the predicates that
constitute the low-energy descriptors, and will be organized around
issues pertaining to general problems of language and information.
The emphasis will be on systems that generate (self-assemble) new
levels of description. These new levels constitute new languages
parasitic on the lower level languages but not reducible to their
predicates. In the self-organizing systems of interest it is the
``coordinate spaces,'' which are themselves evolving, that become the
important objects of study. Instead of assuming a fixed coordinate
space, when the interest focuses on trajectories, attention is devoted
to the coordinate space itself, since this is what provides the semantics.
This approach is very similar to developments in computer
architecture that focus on parallel processing. In these machines
(connection machines, Boltzmann, etc.) the machine language
self-organizes (e.g. programs itself through the emergence of new
stable configurations), and the new predicate descriptions play the
role of symbols in terms of their opacity with respect to the lower
level language. The machine language `gives birth' to the symbolic
level of description. This situation contrasts dramatically with that
of von Neumann machines, for which the symbolic language is
ontologically independent of the machine language. A symbolic
language can run on any of an infinite variety of mechanistic
substrates, the primacy of the symbol prevailing over the substrate
machine. The approach advocated here, puts the focus on the machine
level of interaction, thus preserving an ontological continuity and
avoiding mind/body, syntactic/semantic, etc. problems.
!
Page 3 CSLI Newsletter September 19, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
SUMMARY OF A TALK TO THE DISCOURSE INTENTION AND ACTION GROUP
``Reference and Denotation: The Descriptive Model''
Ami Kronfeld, AI Center, SRI
Tuesday, September 10.
The descriptive approach to the problem of reference has
recently been challenged. One of the most devastating weapons
against it has been the Referential/Attributive distinction. I
argue that this distinction is defined by two criteria which are
independent of each other. The first is the ability to refer using
the ``wrong'' description; the second is based on the notion of
``having a particular object in mind.'' The first criterion is
explained in terms of a distinction between a functionally relevant
description (where the description is used only to identify), and a
conversationally relevant description (where the description takes
part in a Gricean implicature). The second criterion is explained
in terms of the de-re/de-dicto distinction. I examine the claim
that an individual concept is neither necessary nor sufficient for
a de-re belief, and I argue that a Russellian notion of
acquaintance and a theory of the pragmatics of reporting beliefs
can provide a descriptive account of de-re thought. The discussion
that followed the talk focused on (a) the ability of the
descriptive model to handle reference to objects that were
perceived in the past, (b) the role of the self in the
individuation of beliefs, and (c) whether the concept of ``simple''
reference, where the description is only functionally relevant, is
really necessary. --Ami Kronfeld
-------
∂20-Sep-85 0040 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa separating DL and NL using an oracle ?
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 00:40:18 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Fri 20 Sep 85 00:33:36-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Fri 20 Sep 85 00:33:43-PDT
Received: by wisc-rsch.arpa; Fri, 20 Sep 85 01:40:21 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Fri, 20 Sep 85 01:32:49 cdt
Received: from sally.UTEXAS.EDU by wisc-crys.arpa; Fri, 20 Sep 85 01:31:34 cdt
Date: Thu, 19 Sep 85 13:11:26 cdt
From: krishna@sally.UTEXAS.EDU
Posted-Date: Thu, 19 Sep 85 13:11:26 cdt
Message-Id: <8509191811.AA21205@sally.UTEXAS.EDU>
Received: by sally.UTEXAS.EDU (4.22/4.22)
id AA21205; Thu, 19 Sep 85 13:11:26 cdt
To: theory@wisc-crys.arpa
Subject: separating DL and NL using an oracle ?
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
I have read somewhere that separating deterministic logspace
from nondeterministic logspace using an oracle would imply
separating the classes in the unrelativised case.
Can somebody give pointers about this result. I am specially
interested in the case where the oracle is NOT a random oracle.
Specific references or a proof would be helpful!!
Thanks in advance.
∂20-Sep-85 1019 VSINGH@SUMEX-AIM.ARPA Comments
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 10:19:29 PDT
Date: Fri 20 Sep 85 10:14:55-PDT
From: Vineet Singh <vsingh@SUMEX-AIM.ARPA>
Subject: Comments
To: aap@SUMEX-AIM.ARPA
Message-ID: <12144795632.39.VSINGH@SUMEX-AIM.ARPA>
This is an advertisement for my paper "PM: A Parallel Execution Model
for Backward-Chaining Deductions". It is available as KSL-85-18 in
bldg. C. Any comments will be appreciated. I am including the
abstract below.
Abstract
This paper describes @i[PM], an execution model for automating
backward-chaining deductions on multiple processors. The term
@i[execution model] refers to the state, messages and procedures
required to perform the computation @i[correctly]. The target
multiprocessor is characterized by (1) a large number of small
processors, (2) inter-processor communication via messages, and (3) a
distributed database. The key distinguishing feature of @i[PM] is
simultaneous exploitation of @i[and-parallelism], @i[or-parallelism]
and @i[pipelining] in this scenario.
Happy reading!
Vineet
-------
∂20-Sep-85 1211 NEUMANN@SRI-CSLA.ARPA RISKS-1.15
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 12:11:19 PDT
Date: Fri 20 Sep 85 10:34:12-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.15
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-FORUM Digest Friday, 20 Sep 1985 Volume 1 : Issue 15
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
SDI Panel at 8th ICSE in London (David Weiss)
Risks to the Moderator (PGN)
Mailer Protocol Woes (Marty Moore)
Another Horror Story -- Sidereal Time Rollover (Marty Moore)
Article: Health Hazards of Computers (Ted Shapin)
Two More SDI Related Queries (douglas schuler)
CAL ID -- computerized fingerprint system (douglas schuler)
Rejections:
Either your contributions are drifting off the mark, or I must be jacking
up my standards (or both). I rejected several items this time.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Wed 18 Sep 1985 16:51:10 EST
From: David Weiss <wanginst!weiss@nrl-css.arpa>
Subject: SDI Panel at 8th ICSE in London
To: RISKS@SRI-CSLA
Panel Discussion on the Strategic Defense Initiative at the 8th
International Conference on Software Engineering
One of the more interesting sessions at the 8th International
Conference on Software Engineering was a discussion of software for
the Strategic Defense Initiative (SDI). The moderator was Manny
Lehman and the panelists were Fred Brooks, David Parnas, and Alan
Perlis. The discussion was originally intended to be a debate, but
Fred Brooks was not willing to participate in a debate because he had
not yet reached a resolution of the issues. (I understand that
volunteers for the position of opposing Parnas in a debate on SDI
were hard to find. Dr. Brooks deserves credit for being willing to
engage in a public exploration of touchy issues about which he feels
unsettled in concert with a strongly opinionated colleague in an
effort for both audience and panel to learn more.)
The discussion started with a presentation by Parnas of the technical
reasons why reliable SDI software cannot be built. (Readers of this
newsletter will be familiar with many of the arguments put forth by
Parnas. A complete discussion in hard-copy is available from him at
the University of Victoria, Department of Computer Science, P.O. Box
1700, Victoria, B.C., Canada.)
Brooks responded with reasons why he thought we could build such a
system. His major point was that we have built similar systems in
the past. He identified the Apollo missions software as an example,
suggesting that we start with such a system and incrementally build
from it towards an SDI system, using what's learned along the way.
Perlis then added a few comments, explaining why SDI software would
be more complex than existing software and why it is of the hardest
type of software to build. His argument was that the SDI system
represents a moving target in terms of requirements and design.
Following some further discussion among the panelists the floor was
opened to technical questions from the audience.
The major place in which Parnas and Brooks seemed to disagree was
whether or not similar systems have been built. Brooks tried to use
the Apollo and Space Shuttle as examples. Parnas's point was that in
those systems everything can be predicted in advance. In an
anti-missile system, the number, shape, and trajectories of launched
missiles can't be predicted. In addition, the system must
distinguish decoys from real warheads. Finally, the defense system
itself will be under attack. As a result, realistic tests and
simulations of operating conditions for such a system could not be
conducted.
All the discussants seemed to agree that an SDI system could not be
built error-free, and that it would not be completely reliable.
Nonetheless, there were advocates of building it on such grounds as
that it would only be needed for a short time, and could be turned
off the rest of the time, or that we now place our trust in systems
that are also untested and probably unreliable.
In summary, there were no good responses to any of the questions that
Dave Parnas raised. Nonetheless, there were arguments put forth for
the construction of an SDI system on the grounds that it need not be
completely reliable.
David Weiss
Wang Institute of Graduate Studies
------------------------------
Date: Thu 19 Sep 85 17:40:08-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Risks to the Moderator!
To: RISKS@SRI-CSLA.ARPA
RISKS-1.15 was ready to go out Wednesday night. Murphy hit in spades. The
SRI MICOM switch for dial-up access was unavailable for two days, and is
still down. An alternative route might have been available through the only
system that receives dial-ups directly from a split-speed modem, but that
system went down for five hours. Several other more circuitous alternative
routes all ran into broken gateway, which resulted from a power failure
Tuesday night. It would not have helped to drive back to SRI, because the
SRI-CSLA (which kept running through all this) was out of net contact as a
result of a gateway problem. All of the gurus were invisible. If you ever
get this issue, you will know that things have improved. Peter
------------------------------
Date: Tue, 17 Sep 85 07:40:58 CDT
From: mooremj@EGLIN-VAX
Subject: Mailer Protocol Woes
To: risks@sri-csl.arpa
Receiving 2 or 3 duplicate messages is a minor annoyance. Receiving over
a hundred is a *major* annoyance. A few weeks ago, a message from SECURITY
(a non-digest, re-mail distribution list) contained a record that was too
long for our mailer to handle. The result was that the message would be
transmitted from Rutgers, and our mailer would have a problem with the long
record. The message would not be successfully acked, but the mailer would
send me the partial message up to the problem. Since the message was not
acked, Rutgers kept remailing it to me. Before the Rutgers wizards flushed
the message, I had received 173 (I think) copies of the partial message;
at times I was receiving one every 15 minutes! This happened just before I
left on vacation, and I was seriously concerned about returning to work and
finding my disk quota used up by N*1000 copies of the busted message...
Marty Moore (mooremj@eglin-vax.arpa)
[I'm glad we're not the only ones! I think the protocols really
need further ruggedization. Thanks. PGN]
------------------------------
Date: Tue, 17 Sep 85 12:41:04 CDT
From: mooremj@EGLIN-VAX
Subject: Another Horror Story -- Sidereal Time Rollover
To: risks@sri-csl.arpa
How many of you real-time programmers have been bitten by time rollover at
midnight? How about *sidereal* time rollover? It happened like this:
In the late 70's I worked on the USNS Redstone, which is the primary tracking
and support ship for at-sea test launches of the Trident Submarine Launched
Ballistic Missile. I wrote a section of program which took telemetry data
from the Trident's Inertial Guidance Unit and reduced it to provide track
data. Now, Inertial Guidance is like the little girl in the famous rhyme:
when it's good, it's very very good, but when it's bad, it's very very bad.
As such, we had some fairly extensive reasonableness checks on the data.
One in particular took the data's time tag (in sidereal hour angle format),
differenced it with a reference hour angle computed at program initialization,
converted the answer to seconds, and compared this to the program's running
time. If the two times were dissimilar, the IG data was rejected. This
check worked beautifully on numerous tests, with both simulated and actual
input data.
Unfortunately, the programmer (blush, cringe, hang head in shame) completely
overlooked the possibility that the sidereal hour angle could reach 2*pi
radians and roll over during the mission. This eventually happened on a "2+2"
test launch. In a "2+2" launch, two missiles are launched close together,
then two more are launched close together after a lengthy delay. The sidereal
hour angle rolled over about five minutes before the first missile was
launched. The program decided that the IG data had a bad time tag and promptly
rejected it. Fortunately, other devices were tracking the missiles; mission
rules stated that if no track data was received for a certain period, missiles
in flight must be destroyed.
During the delay between the first and second missile pairs, I carefully --
very, very carefully -- patched the running program to disable the time check.
On the second pair of missiles, the IG data was great, which was a good
thing, because for about 40 seconds, no other device tracked them; if the IG
had also failed, the missiles would have been destroyed. If the sidereal
rollover had occurred *between* the two pairs of launches...(gulp)
The moral: the check worked great on numerous tests, until a peculiar set of
conditions occurred. When the bug bit, we were able to save the test; but
with just a small change in conditions, we could have destroyed two Trident
missiles unnecessarily. I don't know what they cost, but I'm sure it's at
least $10,000,000 each.
Marty Moore (mooremj@eglin-vax.arpa)
------------------------------
Date: Wed 18 Sep 85 15:59:24-PDT
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: Article: Health Hazards of Computers
To: RISKS@SRI-CSL.ARPA
Phone: (714)961-3393; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
"The Health Hazards of Computers" edited by Art Kleiner. Pages 80-93,
Whole Earth Review, No. 48, Fall 1985, $4.50. PO Box 15187, Santa Ana, CA.
92705, or your news-stand.
"This amalgamation of information, conjecture, experiment, and reporting is
the end of a 12-month odyssey. It started last June, when we were planning
the 'Computers as Poison' issue (Fall '84 WER)."
"We really should have something on the health hazards of video-display
terminals (VDTs)." I said to Kevin and Stewart. "After all, it's a major
uncertainty. You sit with you nose squeezed up against the beast for hours
every day; you hear vague reports of cataracts and birth defects; you hear,
on the other hand, industry groups saying there's nothing wrong with the
machines .... Whom should you believe?"
A tip from Mike Castleman of Medical Self-Care Magazine led me to the
Center for Investigative Reporting in San Francisco. A reporter there named
Diana Hembree had already been investigating VDT radiation health hazards
for several months, with a particular interest in its effects on women
workers -- most VDT terminal grunt workers, such as airline reservation
clerks and data- entry operators are women. At my request, she assembled a
group of investigators to look into potential radiation hazards from
personal computers.
Their original article arrived in time for the Computers as poison issue,
but because it reported on a situation that was simultaneously
controversial, extremely technical, and inconclusive, we didn't feel
comfortable printing the article without scientific review.
Thus we held it and sent it to two dozen physicists, radiologists,
biophysicists, and doctors -- all people with a preestablished interest in
this topic. Diana's original theme wasn't particularly incendiary; it
basically said, "There seems to be a cause for concern, but nothing
conclusive; more research is needed." We got back a dozen replies, some
complimentary and other criticizing us for everything from hysterical
sensationalism to underplaying the danger. Some of those replies led to
further interviews that supplemented Diana's already exhaustive research.
Meanwhile, discussion of the EIES computer network began turning up comment
from other people who had investigated the issue.
Ultimately, I edited Diana's article, plus some of the replies and other
comments into these 14 pages.
The article ends with a bibliography and notes. Ted.
------------------------------
Date: Thu, 19 Sep 85 12:41:36 pdt
From: bcsaic!douglas@uw-june (douglas schuler)
To: RISKS@SRI-CSL
Subject: Two More SDI Related Queries
I have two queries r e l a t e d to SDI but (I hope) of general
risks interest.
1. Does anybody have rough heuristics for comparing the complexity of
large projects? I'd like to see a matrix where several very large
projects were compared feature by feature (e.g. person-years, LOC,
cost, function, etc)
2. I would be very curious to see the results of using Boehm's estimating
techniques (←Software Engineering Economics←) on the SDI software. The
techniques were developed at TRW and, hence, may be applicable to SDI.
Doug Schuler (206) 763-5295
{allegra,ihnp4,decvax}uw-beaver!uw-june!bcsaic!douglas
uw-june!bcsaic!douglas@washington.arpa
------------------------------
Date: Mon, 16 Sep 85 07:55:43 pdt
From: bcsaic!douglas@uw-june (douglas schuler)
To: Neumann@SRI-CSLA.arpa
Subject: CAL ID -- computerized fingerprint system
This isn't really a submission, just a noteworthy subject that I heard on
NPR this morning. The "CAL ID" computer system is a $40 million system
(from NEC) for storing and retrieving finger prints. The system has not
been officially accepted as of yet as only 2 million of the 2.5 million
fingerprinted California citizens are stored. It is still being tested.
The system was used successfully to identify the "nightstalker" from
fingerprints. Only males born since 1960 had been included. Ramirez was
born in February, 1960. It was estimated that the new system will result in
20,000 additional arrests per year in California.
[I thought this was worth including. There are all sorts of
associated risks. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂20-Sep-85 1248 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 12:48:03 PDT
Received: from ames-vmsb.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Sep 85 12:14:09-PDT
Date: 18 Sep 85 18:34:00 PST
From: welch@ames-vmsb.ARPA
Subject: SIGBIG
To: super@su-score.arpa
Reply-To: welch@ames-vmsb.ARPA
Reply-To: "DYMOND, KEN" <dymond@nbs-vms>
NBS PARALLEL COMPUTER BENCHMARK COLLECTION
The National Bureau of Standards, since its founding, has been
concerned with measurement, determining the precise values and metrics
for physical phenomena. The NBS has also made significant contri-
butions to metrology in numerous scientific and engineering
disciplines. In this tradition, the MPC (Measurement for Parallel
Computing) project at NBS is developing a set of metrics and measure-
ment techniques to characterize the performance of parallel processing
systems. As part of that effort, NBS is collecting benchmarks and code
kernels that represent a variety of applications which are candidates
for parallel processing. NBS solicits benchmark codes and kernels from
researchers and scientists. Programs which are computationally
intensive, I/O intensive, vectorizable or not and from non-numeric as
well as from numeric application areas are requested. Especially
welcome are programs which have been used to produce timing or speedup
data on parallel computers, whose measurement results have been or may
be published in the technical literature, and which are in some fairly
widely used and higher-level programming language such as FORTRAN,
"C", LISP, Ada, etc.
Contributions or inquiries should be directed to:
Measurement for Parallel Computing
Institute for Computer Sciences and Technology
Materials Building MS B364
National Bureau of Standards
Gaithersburg, MD 20899 USA
Telephone: 301-921-3274
ARPANET: MEASURE@NBS-VMS
------
------
∂20-Sep-85 1751 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa Final FOCS Forewarning
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 17:51:31 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Fri 20 Sep 85 17:45:40-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Fri 20 Sep 85 17:43:54-PDT
Received: by wisc-rsch.arpa; Fri, 20 Sep 85 19:23:56 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Fri, 20 Sep 85 19:20:41 cdt
Message-Id: <8509210020.AA14822@wisc-crys.arpa>
Received: from CSNET-RELAY.ARPA by wisc-crys.arpa; Fri, 20 Sep 85 19:20:36 cdt
Received: from uoregon by csnet-relay.csnet id aa08603; 20 Sep 85 20:10 EDT
Received: by uo-vax3.UONET (4.12/1.0.uoregon)
id AA13115; Fri, 20 Sep 85 15:21:34 pdt
Date: Fri, 20 Sep 85 15:21:34 pdt
From: Fall Conference Mail <focs%uoregon.csnet@CSNET-RELAY.ARPA>
Posted-Date: Fri, 20 Sep 85 15:21:34 pdt
To: theory@wisconsin.ARPA
Subject: Final FOCS Forewarning
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
A final reminder on advance registration and room reservations for FOCS -
The deadline for Advance Registration is September 27th. Non-student
registration fees go up by $35 after that date. This policy is firm.
The quoted room rates at the Marriott presume reservations 21 days in
advance of arrival. Rates are likely to be considerably higher in
the absence of such reservations.
Also, if you are counting on the US Mail, it travels here via covered
wagon over the Oregon Trail. There are already rumors that Grant's
Pass is snowed in.
∂20-Sep-85 2106 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa parallel machine bibliography
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 21:06:36 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Fri 20 Sep 85 20:59:26-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Fri 20 Sep 85 20:59:34-PDT
Received: by wisc-rsch.arpa; Fri, 20 Sep 85 22:44:29 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Fri, 20 Sep 85 20:23:44 cdt
Received: from CSNET-RELAY.ARPA by wisc-crys.arpa; Fri, 20 Sep 85 20:23:38 cdt
Received: from lsu by csnet-relay.csnet id a008909; 20 Sep 85 21:14 EDT
Received: by lsu.CSNET ; Fri, 20 Sep 85 13:15:30 cdt
Date: 20 Sep 1985 13:13-EST
From: Steve & <cater%lsu.csnet@CSNET-RELAY.ARPA>
Subject: parallel machine bibliography
To: theory@uwisc.csnet
Message-Id: <496088003/cater@lsu>
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
I am constructing a bibliography for the general topic of parallel
automata. Subjects include
any parallel machine (TM, stack machine, etc.)
recursive machines
cellular automata
as well as anything remotely related to any of the above. If you have any
references that might apply, please send them to me at
cater@lsu.CSNET
If there is demand for the results, I am willing to either mail
individual copies of the bibliography (small demand), or post the
results on the net (large demand).
Thanks.
Steven Cater
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
∂21-Sep-85 1550 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #17
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 21 Sep 85 15:50:14 PDT
Date: 21 Sep 85 1549-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #17
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Saturday, 21 Sep 1985 Volume 1 : Issue 17
Today's Topics:
IJCAI-85 abstracts: omission
Connectionist network teaching / learning tool
Parallel machine bibliography
Parallel rule execution: examples needed
----------------------------------------------------------------------
Date: Saturday, 21 September 1985 15:34-PDT
From: Byron Davies <Davies@SUMEX-AIM.ARPA>
Re: IJCAI-85 abstracts: omission
I inadvertently omitted the following abstract from the collection of
IJCAI-85 articles in the last digest. No offense was intended; my
apologies to the authors.
Yes, An SIMD Machine Can Be Used For AI
Ruven Brooks
Rosalyn Lum
ITT
Nearly all of the proposed parallel architectures for artificial
intelligence applications use a multiple instruction, multiple data
stream (MIMD) approach. While this approach offers the greatest
opportunity for the ultimate exploitation of parallelism, it has been
difficult to actually achieve a high level of parallelism in practice
because most of the existing algorithms require a higher
interprocessor communications bandwidth than the hardware can achieve.
An alternate approach is the use of single instruction, multiple data
stream parallelism (SIMD) machines. While SIMD machines do not offer
the same ultimate exploitation of parallelism as MIMD architectures,
they may, in fact, procide more useable parallelism. This is because
they can be treated as serial machies with very long data words, so
that existing algorithms may be more readily adapted in ways which
better use available parallelism. We illustrate this concept with the
Cellular Array Processor (CAP) being developed at the ITT Advanced
Technology Center. This SIMD architecture is based on a rectangular
processing array which accesses a single memory and which has very
high speed data paths among the processing elements. We discuss the
implementation and manipulation of data for two applications on the
CAP: the OPS5 production interpreter and a representation of an
associative network. The expected performance of the CAP in these
applications will also be presented.
------------------------------
Date: Friday, 13 September 1985 13:22-PDT
From: Hon Wai Chun <hon%brandeis.csnet at CSNET-RELAY.ARPA>
Re: Connectionist network teaching / learning tool
A connectionist network teaching / learning tool called AINET-1 is available
for distribution (educational and research purposes only) from the Computer
Science Department, Brandeis University.
AINET-1 is a graphic-oriented software package which can be used to
interactively create, manipulate, and experiment with connectionist
networks. Most commands are conveniently driven by a mouse. Nodes in
AINET-1 are shaded to reflect their activation levels. Once a network is
created, the user can run an animated simulation (network relaxation). In
the simulation, AINET-1 will change the various node shadings as the
activation levels change during each run cycle. After a simulation, the
user can plot the results or display tables of previous activation levels.
Networks can be stored into binary files and reloaded later for further
editing.
AINET-1 is intended to be used mainly as a learning tool to give the user a
flavor of how connectionist networks behave. A more sophisticated version,
called AINET-2 (under development), may be useful for development work.
AINET-1 is written in Symbolics Common Lisp and presently runs on Symbolics
Lisp machines (Release 6.0). The system is offered on a non-commercial,
non-disclosure, and as-is basis for a nominal fee.
The fee is $150 for universities, and $250.00 for laboratories. Interested
parties should send requests to (or call).
Hon Wai Chun hon@brandeis.csnet
Computer Science
Brandeis University
Ford 232A
Waltham, MA 02254
617-647-2650 or
617-647-2119 (main-office)
------------------------------
Date: 20 Sep 1985 13:13-EST
From: Steve & <cater%lsu.csnet at CSNET-RELAY.ARPA>
To: theory at uwisc.csnet
Re: parallel machine bibliography
[Forwarded to PARSYM by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
I am constructing a bibliography for the general topic of parallel
automata. Subjects include:
any parallel machine (TM, stack machine, etc.)
recursive machines
cellular automata
as well as anything remotely related to any of the above. If you have any
references that might apply, please send them to me at:
cater@lsu.CSNET
If there is demand for the results, I am willing to either mail
individual copies of the bibliography (small demand), or post the
results on the net (large demand).
Thanks.
Steven Cater
------------------------------
Date: Tue, 17 Sep 85 09:04:36 pdt
From: Thomas L. Zimmerman <zimmer%marlin at nosc.ARPA>
To: AIList
Re: Parallel Rule Execution
[Forwarded to PARSYM by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
The Naval Ocean Systems Center (NOSC) and Goodyear Aerospace are
working on a series of experiments to demonstrate the feasibility of
running expert systems on the Goodyear ASPRO parallel processor. A
unique representation for rules and data has been developed which on
paper allows the ASPRO to test 2,000,000 rules per second for
satisfaction. This representation scheme does put some limitations on
the system involved - it appears to require a very pure production
system with no embedded control or functions in the rules. So far a
small (500 rule) system was written with this application in mind and
run on both a Symbolics and the ASPRO sucessfully. We would now like
to convert an existing sequential expert system for parallel execution
in order to determine the degree of speedup actually available and to
discover the limitations of converting a system not originally
designed for this application. Unfortunatly I am having trouble
finding a system to convert for this demonstration - which is why I am
appealing to all of you. We need a reasonably sized (200-700 rule)
system, preferably military in character, that meets the above
limitations that we can attempt to run on our parallel inference
engine. This would be a no-cost way for someone to have their system
speeded up by an estimated three orders of magnitude. Any takers? If
you're interested please contact me:
Lee Zimmerman
Naval Ocean Systems Center
Code 421
San Diego CA 92152
(619) 225-6571 or zimmer@nosc
------------------------------
End of PARSYM Digest
********************
∂22-Sep-85 2315 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA PLANLUNCH reminder
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 22 Sep 85 23:13:09 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Sun 22 Sep 85 23:07:58-PDT
Date: Sun 22 Sep 85 23:00:12-PDT
From: LANSKY@SRI-AI.ARPA
Subject: PLANLUNCH reminder
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, rsimmons@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
araya@XEROX.ARPA, frayman@XEROX.ARPA, suchman@XEROX.ARPA, weld@XEROX.ARPA,
mittal@XEROX.ARPA, dekleer@XEROX.ARPA, trigg@XEROX.ARPA
THE SKY IS A BLUE COLOR
Marcel Schoppers
SRI International AI Center
11:00 AM, MONDAY, September 23
SRI International, Building E, Room EJ228 (new conference room)
I present a representation which will allow us to encode and
access much of the information contained in simple descriptive
statements. "The sky is a blue color" entails that blue is a
color, that the sky has a color, that the sky is blue, that the
sky is visible, and that the sky is located both spatially and
temporally. These generalizations are so trivial that they border
on presuppositions, and they have consequently been taken for
granted in semantic nets and frames. Making such information
explicit greatly increases the density and usefulness of stored
knowledge. One interesting application is to disambiguate an
adjective/predicate to suit a given noun/extension.
My representation is parsimonious, having O(three) primitive con-
structs (link types); is highly irredundant, since blue(sky) and
color(blue) reference the same blue; and is static, being inten-
ded to formalize and implement "massively parallel" deterministic
connectionist question-answering systems. Predicates, relations,
and simple forms of quantification all emerge as by-products of
function applicability and set inclusion. Viewed as a logic the
representation is potentially O(w), intensional and inconsistent.
The talk will touch on issues in philosophy of logic and linguistics.
I will especially appreciate constructive criticism in those areas,
as I am a novice there.
-------
∂23-Sep-85 0342 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #18
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 23 Sep 85 03:41:56 PDT
Date: 23 Sep 85 0327-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #18
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Monday, 23 Sep 1985 Volume 1 : Issue 18
Today's Topics:
Another overlooked IJCAI abstract
Parallel symbolic processing in Japan
----------------------------------------------------------------------
Date: Sun 22 Sep 85 20:08:03-EDT
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: another overlooked IJCAI abstract
Symbols Among the Neurons:
Details of a Connectionist Inference Architecture
David S. Touretzky and Geoffrey E. Hinton
Computer Science Department
Carnegie Mellon University
ABSTRACT:
Pattern matching and variable binding are easily implemented in
conventional computer architectures, but not necessarily in all
architectures. In a distributed neural network architecture each symbol
is represented by activity in many units and each unit contributes to
the representation of many symbols. Manipulating symbols using this
type of distributed representation is not as easy as with a local
representation where each unit denotes one symbol, but there is evidence
that the distributed approach is the one chosen by nature. We describe
a working implementation of a production system interpreter in a neural
network using distributed representations for both symbols and rules.
The research provides a detailed account of two important symbolic
reasoning operations, pattern matching and variable binding, as emergent
properties of collections of neuron-like elements. The success of our
production system implementation goes some way towards answering a
common criticism of connectionist theories: that they aren't powerful
enough to do symbolic reasoning.
------------------------------
Date: Mon, 23 Sep 85 14:36:49 EST
From: munnari!aegir.oz!crw@seismo.CSS.GOV (charles watson)
Subject: PARALLEL SYMBOLIC PROCESSING IN JAPAN
PLEASE FORWARD TO INTERESTED PARTIES
JAPAN TRIP REPORT - 13 Aug 85 to 3 Sep 85
Charles Watson
Division of Information Technology
CSIRO, PO Box 4, Woodville, SA 5011
This report describes research at 12 Japanese laboratories
visited by the author. The main goal of the visit was to see Japanese
research in the areas of parallel symbolic computing hardware, and VLSI
design tools and methodology.
THE INSTITUTE FOR NEW GENERATION COMPUTER TECHNOLOGY (ICOT)
ICOT was started in 1982 as the flag-ship for the Japanese Fifth
Generation Computer Systems (FGCS) project. Researchers (with an average
age under 30) are drawn from Japanese companies for short terms
(typically 2 or 3 years). The high turnover of researchers provides
rapid dissemination of expertise to industry.
Shinichi Uchida introduced the work at ICOT and demonstrated
some prototype hardware. ICOT has about 10 Personal Sequential Inference
(PSI) machines for FGCS research ranging from natural language
translation to operating system development. Each PSI has 80 Mbytes of
main memory using 256K DRAMs on 16 printed circuit boards (PCBs), and 11
PCBs of MSI TTL for the CPU. They are currently implementing a single
board CPU with gate arrays.
They have a large relational database machine (DELTA) for
research in knowledge acquisition and retrieval, and parallel
processing. ICOT is responsible for co-ordinating many other research
projects in the major Japanese electronics companies, and the
Universities. These include several parallel inference machines (PIM)
using either dataflow or reduction as the computational mechanism, and
an implementation (called CHI) of Warren's recent Prolog instruction
set.
OKI ELECTRIC INDUSTRY CO. LTD. (SYSTEMS LABORATORY)
Hiroshi Yasuhara is manager of the AI Section. He has published
work on speech recognition and an abstract Prolog machine based on
bundled OR-parallelism. His group is now working on the operating system
(SIMPOS) for the PSI machine, and on parallel inference. Their parallel
inference machine (PIM-D) is data-flow based, and uses a hierarchical
bus structure for passing instruction packets and data. It utilizes both
AND and OR parallelism. Their prototype has two clusters connected by a
token bus. Each cluster contains 4 processing elements (PEs) and 4
structure memories (SMs) and a local bus. Each PE uses 8 PCBs of TTL
(eg. AMD 2901 bit-slice) and each SM uses 3 PCBs. Simulation of the
PIM-D shows reduced utilization for more than 16 PEs. This is due to
limited bus bandwidth, and limited parallelism in the test programs. The
simulation of 64 PEs took 4 hrs CPU on a VAX 11/780.
ELECTROTECHNICAL LABORATORY (ETL)
ETL is the largest national research organization in Japan, with
560 researchers in the areas of energy, measurement, electronics and
information processing. It has been located at Tsukuba Science City
since 1979. Motoi Suwa is chief of the Man-Machine Systems Section.
Their work includes image and speech processing, and knowledge based
systems.
Toshitugu Yuba is chief of the Computer Architecture Section.
They have a data-flow computer for scientific computation (SIGMA-1). The
single PE prototype has 6 PCBs of TTL and is being redesigned as a
single board of gate array chips. Their target for 1987 is a 100 Mflops
MIMD machine with about 100 PEs. They also have an 8 PE prototype of a
data-flow Lisp machine (EM-3) based on MC68000 processors. This is being
used as test-bed for new parallel control mechanisms. For example, the 4
queens problem took 10 seconds, and 10,000 tokens to produce both
solutions, giving a utilization of 70% for 8 PEs. The target
implementation for 1987 is a 500 KLips, 100 processor Lisp machine. It
will utilize parallel evaluation of conditionals (COND statement) and
concurrent procedure calls.
NTT ELECTRICAL COMMUNICATION LABORATORY (MUSASHINO)
NTT provides most of Japan's domestic telecommmunications
services. Ryuzo Hasegawa has a small research group working on parallel
execution of Logic Programs. They have a single PE TTL prototype of
their data flow machine (DFM), and plan a gate-array implementation. The
DFM applies lenient CONS mechanism for eager and lazy evaluation of list
structures. Dynamic load balancing is applied at all levels of the
network hierarchy. They have simulator for DFM that gives a dynamic
graphic representation of token flow.
Other work at Musashino includes robotics, recognition of
hand-drawn Chinese and Japanese characters, natural language
translation, and speech processing.
DEPT. OF ELECTRICAL ENGINEERING, UNIVERSITY OF TOKYO
They have a prototype relational data-base machine called GRACE,
and a parallel inference engine (PIE). The PIE prototype has a single
PE. They plan to build a 256 PE PIE machine when funds become available.
Software simulation predicts a utilization of 60% to 70% It will use
OR-parallelism.
DEPT. OF COMPUTER SCIENCE, TOKYO INSTITUTE OF TECHNOLOGY
Naoyoshi Tamura demonstrated a bottom-up parser for English
sentences. It uses attribute grammars, to distinguish context dependent
semantics. All possible parsings for ambiguous sentences are generated.
Tomohiro Yoneda has developed a fault tolerant multiprocessor.
His prototype uses 4 busses and 4 PEs. Computations are triplicated, and
the 4th PE is a hot spare to be switched in when the three active PEs
have differing results. The faulty PE becomes the new spare when
repaired. Data transfer is also fault tolerant, using triple modular
redundancy (TMR) and a spare bus.
DEPT. OF APPLIED PHYSICS, OSAKA UNIVERSITY
Hiroshi Yasui has developed a multiprocessor LISP machine
(EVALIS). The prototype has 2 PEs and took about a man year to build.
Utilization is over 90% for 2 PEs. The 8 queens problem took 6.31
seconds on a single PE and 3.31 seconds on 2 PEs. Lists are evaluated
concurrently by spawning NCONC evaluations. Microcode can also be loaded
for diagnostics and Prolog interpretation. An interesting feature is
special CAR and CDR registers for rapid access to LISP structures.
DEPT. OF INFORMATION SCIENCE, KYOTO UNIVERSITY
Shinji Tomita has developed a microprogrammable multi-processor
(QA-2). The prototype has 4 arithmetic logic units (ALUs), and is built
from 17,000 ECL and Schottky TTL ICs. It is used as a test-bed for
several projects, including a parallel 3-D graphics processor, pipelined
arithmetic calculation, and a parallel reduction machine for Prolog
(KPR). KPR applies OR-parallelism and pipelined AND-parallelism, and is
demand driven. A prototype is under construction. Several sequential
Prolog machines have also been emulated on the QA-2, including an
implementation of Tick & Warren's pipelined processor.
Other work in the department includes arithmetic hardware using
redundant binary representation, circuit simulators, and computational
complexity. The data processing centre has a 250 Mflops VP-100, and a
FACOM M-382 main-frame.
NTT ELECTRICAL COMMUNICATION LABORATORY (ATSUGI)
NTT have done some excellent work in VLSI Design, and IC
fabrication technology. Technological innovations include a self aligned
process for 1 micron bipolar gates with 30 picosecond gate delays;
implanted oxide isolation; wafer planarization for multi-layer wiring;
and trench capacitors, used now in most commercial Japanese 1 megabit
DRAMs. INTEL, the leading US commodity chip manufacturer is trying to
compete in the 1 megabit DRAM market with low density horizontal
capacitors. No wonder the Americans are loosing the memory market to the
Japanese. Their clean rooms have overhead tracks for wafer transport to
minimize human contact.
In the area of VLSI Design they have a floorplanner (CHAMP), a
logic synthesis system (ANGEL), integrated into their
standard-cell/gate-array design environment. They have an array
processor (AAP) with 65,536 PEs, for auto place and route and logic
simulation.
They also have a prototype Prolog machine using content
addressable memory (CAM) chips for binding variables. The expected
performance is 100 kLips.
NEC VLSI DEVELOPMENT DIVISION, KAWASAKI
NEC has a 2-D gate-array compaction system (COCKTAIL), a
symbolic layout system (ADULTS) for automatic cut selection and
non-orthogonal grid-free compaction, and a PC-based schematic entry
system (VISTAS).
TOSHIBA R&D CENTER, KAWASAKI
Tadashi Shibata showed me the clean rooms used to develop their
1 Megabit DRAMs. They have excellent quality control. When the 1 M DRAM
was transferred from a development fabrication line to a brand new
production line the initial yield was 10% This compares with new lines
in the past taking as much as a year to come up to a workable yield. I
saw plasma etched line widths of 0.1 microns, and E-beam testing of ICs
with 0.1 micron positioning resolution and a 20 mV signal level
resolution. This enables analog transients at the edge of a submicron
gate to be measured. They are also developing robot controlled wafer
transport and processing.
In the area of VLSI design, they have a logic synthesis system
based on a hierarchical hardware description language, and a procedure
for placing processors and memories on a single chip with gate array
glue logic.
FUJITSU LABORATORIES, INFORMATION PROCESSING DIVISION, KAWASAKI
Fujitsu's FACOM alpha is a commercial LISP/Prolog machine with a
hardware stack, costing about $100,000, and with 3 times the performance
of the Symbolics 3600. They also have a prototype OR-parallel machine
for executing pure Prolog. They have an array processor for high
performance parallel graphics. Other work includes character
recognition, VLSI Design, expert systems, and robotics.
CONCLUSION
I found the Japanese researchers very courteous and open about
discussing research ideas, but sometimes the language barrier limited
communication. For many researchers, translating work into English is
their hardest task. Speaking only English, I probably saw just the tip
of the iceburg. I was pleasantly surprised by the high quality of the
computing research I did see. Considering the Japanese ability for rapid
commercialization of technical innovation, we can expect some exciting
developments in the next few years. It is paradoxical that the highly
competitive Japanese electronics companies seem to co-operate so well
with government agencies such as MITI and ICOT. There is a lot we can
learn from the Japanese.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Charles Watson, CSIRO, PO Box 4, Woodville, S.A. 5011, Australia.
UUCP: {decvax,pesnta,vax135}!mulga!aegir.dmt.oz!crw
PHONE: +61 8 268 0137 ARPA: crw%aegir.dmt.oz!crw@seismo.arpa
CSNET: crw@aegir.dmt.oz
------------------------------
End of PARSYM Digest
********************
∂23-Sep-85 0651 PATASHNIK@SU-SUSHI.ARPA AFLB resumes
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 23 Sep 85 06:51:14 PDT
Date: Mon 23 Sep 85 06:47:54-PDT
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: AFLB resumes
To: aflb.all@SU-SUSHI.ARPA
AFLB starts the year with Umesh Vazirani as our speaker on
October 3 and Eli Shamir on October 10. I'll send abstracts early
next week, but in the meantime please let me know if you'd like to
speak later this quarter. The open dates are October 17, October 31,
November 7, November 14, November 21, December 5, and December 12.
Also let me know if you'd like your address in the mailing list
changed or if you know anyone who'd like to be added to the list.
Send requests to me at aflb-request@su-sushi.arpa.
--Oren
-------
∂23-Sep-85 0847 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@wisc-rsch.arpa Reminder, COming up this Friday
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 23 Sep 85 08:47:10 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Mon 23 Sep 85 08:42:08-PDT
Received: from wisc-rsch.arpa by SU-SCORE.ARPA with TCP; Mon 23 Sep 85 08:42:23-PDT
Received: by wisc-rsch.arpa; Mon, 23 Sep 85 10:16:03 cdt
Received: from wisc-crys.arpa by wisc-rsch.arpa; Mon, 23 Sep 85 09:13:23 cdt
Message-Id: <8509231413.AA08979@wisc-crys.arpa>
Received: from cs.columbia.edu by wisc-crys.arpa; Mon, 23 Sep 85 09:13:13 cdt
Date: Mon 23 Sep 85 10:09:48-EDT
From: Zvi Galil <GALIL@COLUMBIA-20.ARPA>
Subject: Reminder, COming up this Friday
To: theory@WISC-CRYS.ARPA
Sender: udi@wisc-rsch.arpa
Resent-From: udi@wisc-rsch.arpa (Udi Manber)
Resent-To: theory:;
THE
SEVENTH THEORY DAY
at Columbia University
Sponsored by the Department of Computer Science
FRIDAY, SEPTEMBER 27, 1985
10:00 PROFESSOR JOHN E. HOPCROFT
Cornell University
"MATHEMATICAL PROBLEMS IN OBJECT
REPRESENTATION SYSTEMS"
11:00 PROFESSOR LASZLO LOVASZ
Eotvos Lorand University, Budapest, Hungary
"MATCHINGS, POLYHEDRA,
LATTICES, AND ALGORITHMS"
2:00 DR. FAN K.R. CHUNG
Bell Communications Research
"DYNAMIC SEARCH ON GRAPHS"
3:00 PROFESSOR TOM LEIGHTON
Massachusetts Institute of Technology
"WAFER-SCALE INTEGRATION AND
THE GRID RECONSTRUCTION PROBLEM"
Coffee will be available at 9:30 a.m.
All lectures will be in the Kellogg Conference Center on the
fifteenth floor of the International Affairs Building, 118th
Street and Amsterdam Avenue.
The lectures are free and open to the public.
Call (212) 280-2736 for more information.
-------
-------
∂23-Sep-85 1005 RICHARDSON@SU-SCORE.ARPA Sr. Faculty Meeting
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Sep 85 10:05:02 PDT
Date: Mon 23 Sep 85 09:57:47-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Sr. Faculty Meeting
To: tenured@SU-SCORE.ARPA
Message-ID: <12145578945.18.RICHARDSON@SU-SCORE.ARPA>
There will be a sr. faculty meeting following the general faculty meeting
at 2:30 on September 24 in Margaret Jacks Hall Conference Room 146.
Anne
-------
∂23-Sep-85 2016 PATASHNIK@SU-SUSHI.ARPA [Andrew Yao <YAO@SU-SCORE.ARPA>: Lower Bound Course]
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 23 Sep 85 20:16:31 PDT
Date: Mon 23 Sep 85 20:13:11-PDT
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: [Andrew Yao <YAO@SU-SCORE.ARPA>: Lower Bound Course]
To: aflb.su@SU-SUSHI.ARPA
Date: Mon 23 Sep 85 12:14:35-PDT
From: Andrew Yao <YAO@SU-SCORE.ARPA>
Subject: Lower Bound Course
To: aflb.su@SU-SUSHI.ARPA
cc: yao@SU-SCORE.ARPA
Message-ID: <12145603850.28.YAO@SU-SCORE.ARPA>
In this year's CS 366, the emphasis will be on Boolean circuit size complexity.
We will discuss the past and recent results on this subject, and its relations
with Turing computational complexity.
The first meeting will be on Thursday (Sept. 26) as scheduled in the class
schedule booklet. It will be just an organizational meeting, mainly to
fix the meeting time for the rest of the quarter. Tentatively, I would
like to have the subsequent meetings on MW 1:00-2:15 in Margaret Jacks
Hall 301. The reason to make the change of meeting time is, as pointed
out by several people, that many of you may wish to attend the various
talks at MSRI on Tuesdays and Thursdays.
Thanks.
--Andy
-------
-------
∂24-Sep-85 1119 HAUNGA@SUMEX-AIM.ARPA Title and abstract for the SIGLUNCH, September 27th.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 11:19:44 PDT
Date: Tue 24 Sep 85 11:10:07-PDT
From: Ana Haunga <HAUNGA@SUMEX-AIM.ARPA>
Subject: Title and abstract for the SIGLUNCH, September 27th.
To: SIGLUNCH@SUMEX-AIM.ARPA
Message-ID: <12145854258.59.HAUNGA@SUMEX-AIM.ARPA>
KSL/Symbolic Systems Resources Group
Tom Rindfleisch and Bill Yeager
Stanford University
This is the first of several SIGLunches this fall that will summarize work in
each of the five sublabs of the Stanford Knowledge Systems Laboratory (KSL),
including the Heuristic Programming Project, HELIX Group, Medical Computer
Science Group, Logic Group, and Symbolic Systems Resources Group (SSRG). This
week's talk will consist of a brief overview of the KSL as an AI laboratory and
a survey of SSRG research and development activities.
Since 1980, the computing environment for KSL research has been moving slowly
away from central time-shared mainframes (like the SUMEX 2060 and VAX) toward
networked Lisp workstations. Improvements in workstation performance, falling
prices, better packaging, and a wider vendor selection are now accelerating
this transition. Over the next five years, we are proposing to phase out the
SUMEX research mainframes so that all KSL computing will be workstation-based
-- not only research program development but common tasks like text processing,
mail, file management, and budgeting. This raises several important issues
that will require a community system software effort comparable to that in the
1970's that led to the current TOPS-20 and UNIX environments.
How can the user computing environment be improved using workstation bitmapped
graphics and AI methods for more intelligent systems/applications programs?
How can user displays connect flexibly to workstations -- from home, over
remote networks like ARPANET, and locally over Ethernet?
How can the considerable computing power distributed among many workstations be
combined to support individual user tasks?
What are the impacts on network protocols and services (file servers, gateways,
printing, etc.) of large numbers of workstations?
-------
-------
∂24-Sep-85 1144 REULING@SU-SCORE.ARPA LOTS Registration
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 11:44:07 PDT
Date: Tue 24 Sep 85 11:09:48-PDT
From: John Reuling <Reuling@SU-SCORE.ARPA>
Subject: LOTS Registration
To: tas@SU-SCORE.ARPA
cc: instructors@SU-SCORE.ARPA, fl%LOTS-A@SU-SCORE.ARPA
Office: 206 Margaret Jacks, 415/497-3549
Message-ID: <12145854201.24.REULING@SU-SCORE.ARPA>
TAs-
If your course will be using the LOTS Computer Facility this quarter
and you have not yet registered with LOTS, please stop by my office
TODAY and fill out a "Class Registration" form. I will deliver the
completed forms to LOTS this afternoon.
Miscellaneous administrative requests (e.g. setting up class directories,
adding TA's to user groups, etc.) should be directed to FL@LOTSA (Faculty
Liaisons) AFTER you have turned in your registration form.
I am in Margaret Jacks 206.
-John Reuling
-------
∂24-Sep-85 1144 @SU-CSLI.ARPA:KAELBLING@SRI-AI.ARPA Course Announcement
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 11:44:32 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 24 Sep 85 11:39:24-PDT
Date: Tue 24 Sep 85 11:38:08-PDT
From: Leslie Kaelbling <KAELBLING@SRI-AI.ARPA>
Subject: Course Announcement
To: friends@SU-CSLI.ARPA
THE LOGIC OF ROBOT DESIGN
This course will explore theoretical issues in the design of software
for intelligent agents. Its aim is to provide conceptual tools for
coping with complexity in robot design, covering processes from the
sensorimotor level through reasoning, planning, and linguistic
communication, emphasizing the role of formal methods in analysis and
synthesis of robot software.
The following topics will be covered:
- applications of epistemic and temporal logic to robotics
- automata-theoretic models of knowledge
- inference and planning
- logic-based tools for programming intelligent robots.
Some familiarity with basic logic and computer programming will be
assumed. Coursework will consist of problem sets and one programming
assignment.
Instructor : Stan Rosenschein (stan@sri-ai; 859-4167)
Time : TTh 11-12:15
Place : e208
Course number : CS428
Units : 3
TA : Leslie Kaelbling (kaelbling@sri-ai, pack@su-sushi,
k.kaelbling@su-lots-b; 859-2578)
-------
∂24-Sep-85 1209 @SU-SCORE.ARPA:TW@SU-AI.ARPA Program for this year's computer forum
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 12:09:06 PDT
Received: from SU-AI.ARPA by SU-SCORE.ARPA with TCP; Tue 24 Sep 85 11:52:21-PDT
Date: 24 Sep 85 1153 PDT
From: Terry Winograd <TW@SU-AI.ARPA>
Subject: Program for this year's computer forum
To: faculty@SU-SCORE.ARPA
CC: forum-committee@SU-SCORE.ARPA
After a good deal of discussion, we have decided to hold this year's
computer forum on campus, even though the available rooms are not adequate
for its steadily growing size. As a result, we will not stick to our old
single-track format, but will make creative use of parallel sessions,
special-interest sessions (e.g., perhaps at CIS or with KSL), etc. In
order to plan the schedule we need to get started early finding out what
presentations there might be. Of course, there will still be room for
some changes, but anything that doesn't get into the original plan has no
guarantee of finding space and/or time. The forum will be held on
February 5 and 6.
My request to each of you is that by October 11 you let me know the
following:
What students (with corresponding topics) would you like to have speak?
Preference goes to PhD students who will be finishing before the following
forum meeting, and who have not spoken at a forum before.
Which faculty members would like to make individual presentations? In the
past this has been limited to new faculty, for whom it is an introduction to
the forum members, or for faculty speaking on behalf of newly created
groups whose existence is of interest to the members.
What special sessions/events/programs might you be interested in hosting
(i.e, organizing)? What demands would they have for space and time?
Our lack of space may turn out to be a benefit, rather than a problem, if
it helps us get out of the rut and think of new ways to make the forum
better for both the industrial members and our own students and faculty.
I'm counting on your help to do that.
--t
∂24-Sep-85 1317 MARJORIE@SU-CSLI.ARPA CSLI Computing pamphlet
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 13:17:24 PDT
Date: Tue 24 Sep 85 13:12:52-PDT
From: Marjorie Maxwell <MARJORIE@SU-CSLI.ARPA>
Subject: CSLI Computing pamphlet
To: folks@SU-CSLI.ARPA
There is a new CSLI Source pamphlet (explaining the DEC system, Turing,
getting help, MM, & editors) prepared by Susana Wessling, our consultant,
and edited by the rest of the computer staff. It is helpful for new users
and is really just an introduction. I am currently giving it out to the
new accounts but if anyone else is interested in getting a copy, see me
at G-4 in the trailers.
Marjorie
-------
∂24-Sep-85 1346 LIBRARY@SU-SCORE.ARPA Socrates: New Forms, What To Do If You Misplaced Your Old Account
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 13:45:12 PDT
Date: Tue 24 Sep 85 13:41:36-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: New Forms, What To Do If You Misplaced Your Old Account
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12145881834.9.LIBRARY@SU-SCORE.ARPA>
I have received the new forms for free Socrates accounts. It you already have
an ITS account, you can search Socrates at no cost on your ITS account. If
you don't have an ITS account you will want to come to the library, fill out
a form, and you will then be given an account that will already be activated.
Since it is the beginning of the year, it may be best if you send me an
electronic note that you will be coming to the library to get a form. That
was I can attempt to have enough forms on hand at all times. Just send a
message with the Subject: Socrates Account and include your name etc.
If you had an account last year and have misplaced your information. You
may call 497-0020 and Richard Clark will verify your name and ID number
and give you your account information.
The enhanced version of Socrates will not be up this week. It may be up
next week.
Harry Llull
-------
∂24-Sep-85 1400 BSCOTT@SU-SCORE.ARPA Salaries
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 14:00:15 PDT
Date: Tue 24 Sep 85 13:55:41-PDT
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: Salaries
To: Faculty@SU-SCORE.ARPA
cc: BScott@SU-SCORE.ARPA
Message-ID: <12145884397.45.BSCOTT@SU-SCORE.ARPA>
This is just for CS faculty who are being paid from CS funds: would you all
please check your 9/22 salary payments. We changed account numbers and
salaries and it will be a big help to me if you will make sure you received
the amount of salary you were expecting. There is no need to respond if your
salary was o.k., but I will much appreciate hearing from anyone whose salary
is not as expected.
Thank you.
Betty
-------
∂24-Sep-85 1412 DAVIES@SUMEX-AIM.ARPA No architecture meeting this week
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 14:12:24 PDT
Date: Tue, 24 Sep 1985 14:07 PDT
Message-ID: <DAVIES.12145886464.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: No architecture meeting this week
cc: Davies@SUMEX-AIM.ARPA
There will be no meeting this week.
-- Byron
∂24-Sep-85 1544 LIBRARY@SU-SCORE.ARPA Math/CS Library: New Books
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 15:44:31 PDT
Date: Tue 24 Sep 85 15:40:59-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library: New Books
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12145903567.9.LIBRARY@SU-SCORE.ARPA>
A Geometric Investigation of Reach. ACM Distinguished Dissertation. 1984.
MIT Press. by James Korein.
Numerical Grid Generation: Foundations and Applications. by Thompson,
Warsi, Mastin. Norht-Holland. QA377.T524 1985.
Design and Analysis of Distributed Real-Time Systems. by Paul Fortier.
Intertext Publ. McGraw-Hill. (8512417)
Operating Systems: Structures and Mechanisms. by Philippe Janson.
Academic Press. QA76.6.J364 1985.
Formal Theories Of The Commonsense World. by Jerry Hobbs and Robert
Moore editors SRI International. Ablex Series In Artificial Intelligence.
Q360.F66 1985 c.2
SPSS Graphics. SPSS Inc. HQ32.S62 1985
H. Llull
-------
∂24-Sep-85 1722 @SU-CSLI.ARPA:KAELBLING@SRI-AI.ARPA Room Change
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 17:22:16 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 24 Sep 85 17:17:14-PDT
Date: Tue 24 Sep 85 17:18:22-PDT
From: Leslie Kaelbling <KAELBLING@SRI-AI.ARPA>
Subject: Room Change
To: friends@SU-CSLI.ARPA
The initial meeting of The Logic of Robot Design will be in MJH252
(Building 460), not e308 as previously announced.
-------
∂24-Sep-85 1941 @SU-SCORE.ARPA:fournier@su-navajo.arpa Re: Socrates: New Forms, What To Do If You Misplaced Your Old Account
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 19:41:09 PDT
Received: from su-navajo.arpa by SU-SCORE.ARPA with TCP; Tue 24 Sep 85 19:36:10-PDT
Received: by su-navajo.arpa with Sendmail; Tue, 24 Sep 85 19:36:12 pdt
Date: Tue, 24 Sep 85 19:36:12 pdt
From: Alain.Fournier@su-navajo.arpa, 226C@su-navajo.arpa, 0474@su-navajo.arpa,
2472276 <fournier@su-navajo.arpa>
Subject: Re: Socrates: New Forms, What To Do If You Misplaced Your Old Account
To: LIBRARY@SU-Score, su-bboards@SU-Score
Cc: faculty@SU-Score
I would like a Socrates account. I am a visiting prof. Does that make a difference?
I'll go by the library probably tomorrow. Thanks.
∂24-Sep-85 1951 @SU-SCORE.ARPA:fournier@su-navajo.arpa Re: Socrates: New Forms, What To Do If You Misplaced Your Old Account
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 19:51:34 PDT
Received: from su-navajo.arpa by SU-SCORE.ARPA with TCP; Tue 24 Sep 85 19:48:13-PDT
Received: by su-navajo.arpa with Sendmail; Tue, 24 Sep 85 19:48:14 pdt
Date: Tue, 24 Sep 85 19:48:14 pdt
From: Alain.Fournier@su-navajo.arpa, 226C@su-navajo.arpa, 0474@su-navajo.arpa,
2472276 <fournier@su-navajo.arpa>
Subject: Re: Socrates: New Forms, What To Do If You Misplaced Your Old Account
To: LIBRARY@SU-Score, su-bboards@SU-Score
Cc: faculty@SU-Score
Sorry about unnecessary message. I forgot to shift.
∂25-Sep-85 0104 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #37
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 01:04:27 PDT
Date: Saturday, August 24, 1985 1:32PM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #37
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Monday, 26 Aug 1985 Volume 3 : Issue 37
Today's Topics:
Query - Simulation,
Programming - Building Large Systems,
LP Philosophy - Hewitts Challenge,
Implementation - Performance,
LP Library - Fix & Public Domain
----------------------------------------------------------------------
Date: Mon 12 Aug 85 20:11:56-PDT
From: Larry Widman <WIDMAN@SUMEX-AIM.ARPA>
Subject: Simulation
I am interested in semi-quantitative simulation as an
approach to generating scenarios of causal networks
which include feed-back loops. The scenarios could
then undergo feature extraction to permit temporal
reasoning and learning-from-experience by pattern
matching of specific scenarios with a library of
ideal scenarios ("compiled knowledge") and of
previously seen cases ("experience").
I have implemented such a program in MACLISP for use in
the medical domain. I presented it at the latest meeting
of the Artificial Intelligence in Medicine meeting in
Bethesda, in July. I should think that this approach
would be generally useful, and may well be under independent
investigation by others.
Therefore, I would like to read the logic programming
literature (the Digest being among the best, according
to my colleagues). If you think it is appropriate, you
could insert the above paragraphs into the Digest together
with a request for information from others with similar
interests.
I would of course be happy to summarize the responses for
the Digest.
Thank you for your help. -- Larry Widman
------------------------------
Date: Sun, 18 Aug 85 22:43:03 +0200
From: Anjo@seismo.CSS.GOV
Subject: Building Large Systems
We have had a similar problem with developing a window system
with a large number of utilities on top of Prolog. As the window
system should have a fast user interface (responding to mouse
clicks immediately), Prolog itself is not the most appropriate
language to use. Our solution is implement the user interface
and all the windowing stuff in C, along with text-editors, graphics
editors, the mouse-manager etc. (at the moment this is about 300+
pages of C source code). This package is called PCE. Obviously
the Prolog programmer wants full access to this package, he wants
to create windows, graphical representations of knowledge inside
his Prolog application and get mouse clicks if he needs them.
This calls for bi-directional interface between PCE and Prolog.
Our solution for this problem is to add a small number of
predicates to Prolog that implement object orientedness, and a
few functions that can asserted information available in PCE in
the Prolog data-base (total source code of these functions is
about 15 pages C).
The advantages of this approach (in our case) are that the
performance of the user interface doesn't depend on the performance
of the Prolog interpreter, so all I/O functions are as fast as C can
do it. The small interface assures that PCE can be modified without
also needing to change part in the interface. For example if we
decide to create another lay-out for a window only PCE needs to be
changed, while both the interface between Prolog and PCE, and the
Prolog applications remain unchanged.
Whether an approach like this is also feasible for your problem
depends, I think, on how well you succeed in keeping the interface
between Prolog and the "Data Base System (DBS)" simple. From a
software engineering point of view the saying "small is beautiful"
certainly applies here. I think that it is possible to build an
object oriented shell around a DBS, in that case the approach we
have used becomes possible. A dangerous approach is to add
predicates to Prolog for each operation you need, before long the
interface will be large and porting it to another implementation
of Prolog will for sure give problems. If we need to port PCE
Prolog to another implementation only 15 pages of C-code needs to
be rewritten, which is acceptable.
The Prolog implementation we use is C-Prolog 1.5 with some local
additions. If you would like to have more information or technical
details (the predicates used for instance) let me now it.
Greetings,
-- Anjo Anjewierden
------------------------------
Date: Mon, 19 Aug 1985 12:47 EDT
From: Hewitt@MIT-MC.ARPA
Subject: Prolog will fail as the foundation for AI
Date: Saturday, 17 August 1985 13:36-EDT
From: PEREIRA at SRI-AI.ARPA
Re: Prolog will fail as the foundation for AI
Carl Hewitt's message is based on several misconceptions:
1. (the least interesting one) All the so-called commercially
viable Prolog systems in Lisp are not really Prolog systems
written IN Lisp, but rather Prolog systems written FOR Lisp
machines. Or is it that a microcode sublanguage or Lisp machine
pointer-smashing operations are part of List as we know it?
Yes. They are DEFINITELY part of Common Lisp as we know it
being implementations of reading and writing operations on
record structures. Such implementation methods are NOT part
of Logic as a Programming language.
Without those machine-level operations, those Prolog systems
would run too slow and use too much memory to be useful for
serious Prolog programming. From the Prolog implementation
point of view, what is important about the Lisp machines is
not that they run Lisp, but that they can be microcoded and
have good support for tagged data types and stack operations.
It is important to many users that they can make use of ALL
the software available to the community and not just be limited
to the tiny amountin Prolog. Furthermore in the future good
software will be ported from stand alone Prolog systems to Prolog
implemented on Lisp. However to good Lisp software will not be
able to be ported to the stand alone Prolog systems.
2. If the decisions (actions) of a system are not determined
by its inputs, the system is nondeterministic. Nondeterminism
in a system can be either an artifact of our incomplete knowledge
(or lack of interest) of the detailed operation of the system;
or it can be ``real physical'' nondeterminism. It would take us
to far to discuss whether the second kind of nondeterminism is
``real'' or also an artifact. In any case, most uses of
nondeterminism, say in models of concurrency, are of the first
kind, and can be expressed appropriately in various temporal
dynamic logics. Admittedly, these are not Prolog, but then
Common Lisp is not Lisp 1.5! (Prolog is 13 years old, Lisp 25).
Yes indeed there is a large problem here that poses fundamental
problems for using Logic as a Programming language to make
decisions in Open Systems.
3. The first logic course dictum ``from a contradiction one
can conclude anything'' is getting in the way. Notice that
the dictum says ``can'', not ``must''. There is an enormous
difference between things that are in principle true and
things that an agent knows to be true in a way that can affect
its action. An agent might know ``p'' and ``not p'', but it
might well never come to infer the dreaded totally unrelated
``q'' which IN PRINCIPLE follows from the contradiction. This
inference might not happen either because of inference control
mechanisms of the agent (eg. it uses the set-of-support strategy)
or because the agent's logic is just TOO WEAK to conclude
anything from a contradiction (vide Hector Levesque's work in
the proceedings of the last AAAI). In any case, Horn clauses
(the basis of Prolog) are too weak to represent contradictions
... :-)
I claim that in practice the contradictions lie close to the
surface and occur in any nontrivial application. Thus the
contradictions pose fundamental problems for using Logic as
a Programming Language.
4. The question of whether ``taking action'' fits in a logic
paradigm tends to be answered negatively after an hour's worth
of consideration. If you persist for several years, though,
this question becomes a source of insight on the relations
between knowledge, state and action that is not available to
those who started by dismissing the question after that initial
hour. There is just too much work on logics of knowledge and
action in AI and computer science for me to try to discuss it
here. Some of this work has been applied to logic programming,
either in the form of new logic programming languages based on
temporal or dynamic logics or in representations of temporal
reasoning and decision in, say, Prolog.
I have been thinking about the problem for many years having
designed Micro-Planner, the first "procedural embedding of
logic" programming language in 1967. I claim that the problem
of taking action poses fundamental problems for using Logic as
a Programming language.
5. It is curious to see someone by implication defend Lisp as a
language for expressing the taking of action!
I claim that current Lisp systems are better than current Prolog
systems for taking action because the only ways to take action in
current Prolog systems are kludges.
We know by now that the most difficult issue in ``reactive
systems'' is not EXPRESSING action, but rather keeping it under
control to prevent unwanted interactions. In this area, less
is REALLY more, and highly complex languages like Lisp are
just not suitable for the formal reasoning about programs
that is needed to help us believe our programs do what we
intend. To those who say ``...but we can keep to a carefully
constrained subset of Lisp, use only message passing for
interactions,...'' I will answer that the history of all large
Lisp programs I know (and I think that is a representative sample)
is littered with the brutalized corpses of constrained
programming styles. Anyone who has looked at the current
flavor mechanism in Zetalisp and its use in the window system
will know what I mean...
5. Underlying Carl Hewitt's misconceptions is the old chestnut
``logic is static, systems are dynamic''.
Note that the above quotation is NOT anything that I said.
Any language, be it first-order logic or Lisp, is static;
it is its USE which is dynamic (changes the state of
communicating agents). A good analogy here is the use of
differential equations to model dynamic systems in classical
mechanics. The differential equations themselves do not say
directly what happens when (they are ``static'' in Hewitt's
jargon).
I do not deny that dynamic systems can be DESCRIBED using
logic only that they can be CONTROLLED.
It is their SOLUTIONS that tell us the sequence of events.
Even the solutions are given as static objects (functions
from an open interval of the reals to some space). Does
anyone worry that such equations do not ``really'' describe
the dynamic behavior of a system? Is it not possible to
combine such ``static'' entities with an incremental
solution procedure to build systems that actually control
their (classical mechanical) environment?
I do not believe that the control system can be implemented
using Logic as a Programming language
------------------------------
Date: Tue, 20 Aug 85 11:20:47 PDT
From: Rick McGeer mcgeer%ucbkim@Berkeley
Subject: Prolog In Lisp...
[Hewitt]:
Prolog (like APL before it) will fail as the foundation for
Artificial Intelligence because of competition with Lisp.
There are commercially viable Prolog implementations written
in Lisp but not conversely.
Wrong. I spent the better part of last year attempting to hack
up a decent Prolog in Lisp: the general idea was to use the
Prolog implementation for the top levels of the program, and a
Flavors-like "Object Engine" for low-level data structure hacking:
there were hooks in the logic engine to manipulate data structures
by calling the object-oriented stuff, and the trail was modified
to permit destructive assignment.
To make a long story short, the project failed because I couldn't
get decent performance out of the logic engine. So I threw out all
the data structures stuff and the Object Engine, and concentrated
on squeezing Prolog performance any way I could.
The result, after months of effort, traces, special purpose hacks
for fast unification of special cases, and so forth? 100 LIPS on
the concat loop on a 4MB Vax 11/780 running 4.2BSD. The
implementation was in Franz, Opus 38.91.
Why? Franz is simply too slow. I tried the concat loop, in
interpreted Franz:
(defun concat(l1 l2)
(cond ((null l1) l2)
(t (cons (car l1)
(concat (cdr l1)
l2)))))
and got these results:
Iterations Seconds Lips Equivalent
------------------------------------------------
100 .166 600
250 .3 833.333...
350 .417 840
400 Died N/A
I then tried running the same lists through Franz' native, tail
recursion optimized append function, and got:
Iterations Seconds Lips Equivalent
-----------------------------------------------
100 .03333 3000
250 .06666 3750
350 .1 3500
500 .13333 3750
1000 .26666 3750
Or, in short, compiled Franz runs at about 2.5 times the speed
of interpreted CProlog, and interpreted Franz runs at about half
the speed of interpreted CProlog.
Anyway, these figures were enough to convince me that Prolog in
Lisp wasn't going to be competitive with native-coded versions
(Cprolog and the compilers) for a long time, and I gave up. And
before you mention Lambda's Prolog to me, microcode support is
hardly a Prolog coded entirely in Lisp. Given microcode support
on the PLM, I'm sure that a viable Lisp-in-Prolog could be built.
-- Rick
------------------------------
Date: Tue, 20 Aug 1985 19:04 EDT
From: HEWITT@MIT-XX.ARPA
Subject: Prolog on Lisp vs. Lisp on Prolog
In the exhibitors hall at the IJCAI in Los Angeles, you
can find several commercially viable Prologs on top of
Lisp and Lisp Machines but no commercially viable Common
Lisp on top of Prolog.
Does anyone believe that it will EVER be possible to build
a commercially viable Common Lisp on Prolog?
-- Carl
------------------------------
Date: Tue, 20 Aug 85 16:58:10 PDT
From: Rick McGeer mcgeer%ucbkim@Berkeley
Subject: Prolog on Lisp vs. Lisp on Prolog
I'd be interested to see some figures on the performances
of these Prologs. Last year, various people told me that
any Prolog that didn't perform to the level of Warren's
compiled DEC-10 Prolog (which is to say, 20-30KLIPS)
wouldn't be commercially viable: on a VAX, (other things
being equal) such a Prolog should obtain about 5 KLips.
Now, it's clear that a Prolog In Lisp can't possibly do
better than the Lisp interpreter. Since even compiled Franz
can't hit 5 KLips, it is clear that no Prolog-In-Franz will
be commercially viable. Now, it's possible that dedicated
Lisp machines such as the 3600 or the Lambda can run a variant
of Lisp fast enough that Prolog can run in the commercially
viable range. However, if you're going to make that argument,
then the question you should be posing is whether dedicated
Prolog machines can run Lisp fast. And the answer is, sure
it can: a 200+ KLIP processor can run almost anything fast.
-- Rick.
------------------------------
Date: Wed, 21 Aug 1985 17:53 EDT
From: HEWITT@MIT-XX.ARPA
Subject: Prolog on Lisp vs. Lisp on Prolog
Why should a Prolog on Lisp be limited by the speed of
interpreted Lisp? I would imagine that the limitation
on speed would be that of highly optimized compiled Lisp.
-- Carl
P.S. What is your definition of a KLIP? For what purposes
do you think that KLIPs is a useful measure of performance?
------------------------------
Date: Wed, 21 Aug 85 15:19:58 PDT
From: Rick McGeer mcgeer%ucbkim@Berkeley
Subject: Prolog on Lisp vs. Lisp on Prolog
[Hewitt]:
Why should a Prolog on Lisp be limited by the speed of
interpreted Lisp? I would imagine that the limitation
on speed would be that of highly optimized compiled Lisp.
Well, I'd like to be wrong. If I could think of a way to
compile Prologcode into Lisp, then I'd agree. Unhappily,
I can't. The real trouble is maintaining the state of the
stack.
[Hewitt]:
P.S. What is your definition of a KLIP? For what purposes
do you think that KLIPs is a useful measure of performance?
A KLIP is 1000 Logical Inferences Per Second: I suppose that
would best be defined as succesful unifications, or function
calls. If you are going to argue that this is at best a
flawed measure of performance (since not all clauses are created
equal), then of course I'd agree. Performance studies here at
Berkeley have shown that it's easy to write the same program
two different ways, one of which runs faster and the other at a
higher LIPS rate. Still, a LIP is a handy catchall, much as a
MIP or a FLOP is...
-- Rick
[ Yawn. This definition is old, more or less resolved for
flap, peruse Volume 1 of the Archive -ed ]
------------------------------
Date: Wed, 21 Aug 1985 18:42 EDT
From: Hewitt@MIT-MC.ARPA
Subject: Prolog on Lisp vs. Lisp on Prolog
How do you measure the speed in KLIPS in practice. Do
you just measure the speed of APPEND in Prolog?
--Carl
------------------------------
Date: Wed, 21 Aug 85 18:27:08 PDT
From: Rick McGeer mcgeer%ucbkim@Berkeley
Subject: Prolog on Lisp vs. Lisp on Prolog
That is the way that I do it. Basically, I just
calculate the count of the call tree (not counting
failed unifications). Others may have other ideas.
Of course, you use other benchmarks. concat (or
append, if you prefer) tends to give you a pretty
optimistic answer.
BTW, a word about Common Prolog. It is fairly clear
that Prolog will need destructive assignment before
it becomes commercially viable: it turns out that the
major problem with destructive assignment (undoing the
assignments upon backtrack) is not all that hard to
solve. Once that happens, I imagine that you'll see a
large number of powerful, commercial Prolog systems.
-- Rick
------------------------------
Date: Thu, 22 Aug 85 12:55:46 pdt
From: Allen VanGelder <avg@diablo>
Subject: Re: minor fix for library
To users of my ranpkg in the Prolog library at
SCORE, if any: I replaced the expression
\(1 << (Wsize - 1))
by the more precise version,
\(\(0) << (Wsize - 1))
This has no effect using the current DEC-20 Prolog,
but makes the program less implementation-dependent.
Unfortunately my Cprolog converts large integers to
floating point without being asked, so extensive changes
were necessary to get around that "feature" and these
changes are not in the library.
------------------------------
Date: Mon, 5 Aug 85 10:09:19 pdt
From: Peter Ludemann <ludemann%ubc.csnet@csnet-relay>
Subject: Public domain Prolog, Hope
The August 1985 issue of BYTE magazine has a number of
articles on Declarative Langauges (Prolog, Hope, FP).
Public domain versions of Prolog (from Automata Design
Associates) and Hope (from Imperial college) for MS-DOS
machines are apparently available from BYTEnet at (617)
861-9774. Would some kind soul who lives in that area
please post these to this Digest? Phone lines here are
bad just going across the city; going across the
continent would be a nightmare.
-- Peter Ludemann
------------------------------
End of PROLOG Digest
********************
∂25-Sep-85 1133 CONTRERAS@SU-SCORE.ARPA Parking Stickers
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 11:32:30 PDT
Date: Wed 25 Sep 85 11:28:53-PDT
From: Tina Contreras <CONTRERAS@SU-SCORE.ARPA>
Subject: Parking Stickers
To: Faculty@SU-SCORE.ARPA
cc: Staff@SU-SCORE.ARPA
Message-ID: <12146119817.9.CONTRERAS@SU-SCORE.ARPA>
You'll never believe it but the Police Station finally called and the stickers
are ready, so you'll beable to pick up your sticker from me at 1:00.
Tina
-------
∂25-Sep-85 1202 @SU-SCORE.ARPA:MDIXON@SU-SUSHI.ARPA maps to new student lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 12:02:19 PDT
Received: from SU-SUSHI.ARPA by SU-SCORE.ARPA with TCP; Wed 25 Sep 85 11:59:00-PDT
Date: Wed 25 Sep 85 11:57:56-PDT
From: Mike Dixon <MDIXON@SU-SUSHI.ARPA>
Subject: maps to new student lunch
To: new-phd@SU-SUSHI.ARPA, new-msai@SU-SUSHI.ARPA, new-csms@SU-SUSHI.ARPA,
faculty@SU-SUSHI.ARPA, student-advisors@SU-AIMVAX.ARPA
i've left a bunch of the maps showing how to find the pratts with tina
(the receptionist, second floor). .mike.
p.s. if you haven't rsvp'd yet, what are you waiting for?
pps. if you replied to my earlier message about carpooling and haven't
received a reply, don't worry -- i'm collecting all the responses
and will get back to you soon.
-------
∂25-Sep-85 1353 CHEADLE@SU-SCORE.ARPA Reminder--CSD Reception tomorrow
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 13:53:28 PDT
Date: Wed 25 Sep 85 13:45:52-PDT
From: Victoria Cheadle <CHEADLE@SU-SCORE.ARPA>
Subject: Reminder--CSD Reception tomorrow
To: csd@SU-SCORE.ARPA
Office: Margaret Jacks 258, 497-1519
Message-ID: <12146144756.31.CHEADLE@SU-SCORE.ARPA>
Remember that tomorrow is the annual CSD reception for new
graduate students. It will be held at 4:00 on the patio
between the Psychology building and CS building. Please join
us in welcoming our new students.
Hope to see you all there!
Victoria
-------
∂25-Sep-85 1408 REGES@SU-SCORE.ARPA Department Lecture Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 14:08:44 PDT
Date: Wed 25 Sep 85 14:02:26-PDT
From: Stuart Reges <REGES@SU-SCORE.ARPA>
Subject: Department Lecture Series
To: faculty@SU-SCORE.ARPA
Office: Margaret Jacks 210, 497-9798
Message-ID: <12146147772.29.REGES@SU-SCORE.ARPA>
As a result of the discussion last week, I have taken this course off of the TV
network and have moved it to a room in the history corner. If you are
interested in giving a presentation, please let me know now so that I can work
out the schedule for the quarter. The class meets on Thursdays from 2:45 to 4
starting tomorrow. I'm planning on speaking tomorrow unless I get a last minute
volunteer. I plan to give a general overview of the department and its research
and curriculum. Please let me know if you want to speak on one of the other
Thursdays.
-------
∂25-Sep-85 1412 @SU-CSLI.ARPA:chertok%ucbcogsci@Berkeley.EDU UCB Cognitive Science Seminar--Oct. 1
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 14:10:57 PDT
Received: from UCB-VAX.ARPA by SU-CSLI.ARPA with TCP; Wed 25 Sep 85 14:07:32-PDT
Received: by UCB-VAX.ARPA (5.26/5.9)
id AA04219; Wed, 25 Sep 85 14:08:06 PDT
Received: by ucbcogsci.ARPA (5.5/5.7)
id AA28422; Wed, 25 Sep 85 14:09:11 PDT
Date: Wed, 25 Sep 85 14:09:11 PDT
From: chertok%ucbcogsci@Berkeley.EDU (Paula Chertok)
Message-Id: <8509252109.AA28422@ucbcogsci.ARPA>
To: cogsci-friends%ucbcogsci@Berkeley.EDU
Subject: UCB Cognitive Science Seminar--Oct. 1
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, October 1, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: David Rumelhart, Institute for Cognitive
Science, UCSD
TITLE: ``Parallel Distributed Processing: Explora-
tions in the Microstructure of Cognition''
Parallel Distributed Processing (PDP) is the name which I and
my colleagues at San Diego have given to the class of
neurally-inspired models of cognition we have been studying.
We have applied this class of "connectionist" models to a
variety of domains including perception, memory, language
acquisition and motor control. I will briefly present a gen-
eral framework for the class of PDP models, show how these
models can be applied in the case of acquisiton of verb mor-
phology, and show how such macrostructural concepts as the
schema can be seen as emerging from the microstructure of PDP
models. Implications of the PDP perspective for our under-
standing of cognitive processes will be discussed.
----------------------------------------------------------------
UPCOMING TALKS
Oct 8: Terry Winograd, Computer Science, Stanford
Oct 15: Ron Kaplan, Xerox PARC
Oct 22: Lotfi Zadeh, Computer Science, UCB
Oct 29: Mardi Horowitz, Psychiatry, UCSF
Nov 5: Edward Zalta, CSLI, Stanford
Nov 12: Robert Wilensky, Computer Science, UCB
Nov 19: Richard Alterman, Computer Science, UCB
Nov 26: Eve Clark, Linguistics, Stanford
Dec 3: Bernard Baars, Langley Porter, UCSF
* * * * *
ELSEWHERE ON CAMPUS
Steven Christman will be speaking on ``Visual Persistence'' on
Friday, October 4, 1985, at 4:00 p.m. in the Beach Room, 3105
Tolman Hall, UCB.
∂25-Sep-85 1738 EMMA@SU-CSLI.ARPA Newsletter September 26, No. 47
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 17:38:40 PDT
Date: Wed 25 Sep 85 16:54:08-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter September 26, No. 47
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
September 26, 1985 Stanford Vol. 2, No. 47
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, September 26, 1985
12 noon TINLunch
Ventura Hall ``The Concept of Supervenience''
Conference Room Discussion led by Carol Cleland
2:15 p.m. CSLI Talk
Ventura Hall No talk this week
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, October 3, 1985
12 noon TINLunch
Ventura Hall ``Idealized Cognitive Models'' and ``Metonymic Models''
Conference Room Sections 4, 5 of ``Women, Fire, and Dangerous Things''
by George Lakoff
Discussion led by Douglas Edwards
(Abstract on page 2)
2:15 p.m. CSLI Seminar
Ventura Hall ``Notes from the STASS Underground''
Seminar Room David Israel, CSLI and SRI
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
THIS YEAR'S THURSDAY ACTIVITIES
CSLI's year will be starting next Thursday, October 3, and several
changes have been made.
TINLunches will be organized by Chris Menzel and Mats Rooth, two
CSLI postdoctoral fellows. They will continue to meet at noon in
the Ventura Conference room.
Thursday Seminars will have a different format this year and will
consist of either individual presentations from the postdocs or a
presentation by one of the new projects of its goals and progress.
Thursday Colloquia will be rarer and of more general interest.
Each project will be responsible for one colloquium, and we hope to
have three colloquia a quarter. Time and location of the colloquia
may vary.
Next week's newsletter will contain a list of the new projects and a
tentative calendar for the Fall quarter.
!
Page 2 CSLI Newsletter September 26, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S TINLUNCH
``Idealized Cognitive Models'' and ``Metonymic Models''
Sections 4, 5 of ``Women, Fire, and Dangerous Things''
According to Lakoff, many words are understood by reference to
``Idealized Cognitive Models'' (ICMs) which describe the ideal
circumstances in which the phenomena these words refer to are
conceived to exist. Some uses of a word can only be understood by
treating the word's ICM as true even when it is known to be false in
general. Other uses modify the word's meaning by more or less
explicitly calling the ICM in question or by focusing on cases to
which the ICM clearly fails to apply.
Thus linguistic puzzles can arise. For instance ``bachelor'' is
often defined as ``unmarried man,'' and ``to lie'' as ``to make a
false statement,'' even though it is well known that these terms are
not coextensive with their definitions. When a word is defined, its
ICM is taken for granted, but when a purported example is judged,
failure of applicability of the ICM can make the purported example
illegitimate or at least atypical. The ICMs for ``bachelor'' and
``lie'' fail partly or totally for priests, children, polygamists,
misleading true statements, polite nothings, and accidental errors.
Syncategorematic noun modifiers often affect the ICM. Thus we get
``social lie,'' ``white lie,'' ``eligible bachelor'' (this one
reinforces the ICM), ``foster mother,'' ``surrogate mother,'' and so
on.
ICMs are interesting in that they seem to be used in reasoning
generally, not just in lexical semantics. They are akin to, but not
identical with, various constructs developed for artificial
intelligence, such as frames, scripts, contexts, data pools, etc.
--Douglas Edwards
←←←←←←←←←←←←
ABSTRACT OF NEXT WEEK'S CSLI SEMINAR
``Notes from the STASS Underground''
I will try to explain the meaning and import of one of the hottest
acronyms at CSLI -- ``STASS.'' In particular, I will try to explain
why there should be a Situation Theory as well as a Situation
Semantics. --David Israel
←←←←←←←←←←←←
CSLI TALK
``Verbs and Time''
Dorit Abusch, Tel-Aviv University
Tuesday, October 1, 1 pm, Ventura Conference Room
In ``Word Meaning and Montague Grammar,'' David Dowty analyzed
aspectual clauses in terms of an ``aspectual calculus'' consisting of
stative predicates and operators such as BECOME and CAUSE. For
instance, achievements, including many morphological inchoatives, are
analyzed as having the form lambda x[Become(P(x))]. Accomplishments,
including many morphological causatives, are analyzed in terms of
CAUSE. Dowty and Lauri Carlson noted that some inchoatives, such as
(the verb) ``cool,'' meet the test for process verbs, I discuss these
inchoatives, and similar causatives. The relation between the
operators and the verb classification is complex. I argue that the
classification breaks down for certain causatives, such as the
transitive versions of ``gallop'' and ``darken.''
!
Page 3 CSLI Newsletter September 26, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
AFA SEMINAR
This quarter there will be a small informal seminar going through
Peter Aczel's work on the anti-foundation axiom (AFA) in set theory,
together with some of the applications found by people here at CSLI.
We will start at the beginning, but assume familiarity with the
cumulative hierarchy and ZFC. The seminar will be Thursdays at 4:15
when there is no CSLI colloquium, in the Ventura Conference room. Jon
Barwise will give a brief introduction on September 26, and then we
will organize the rest of the quarter. If you would like to be added
to the AFA mailing list, contact Westerstahl@csli.
←←←←←←←←←←←←
NEW PROJECT MEETING ON ENVIRONMENTS
Mondays 1-2 in the trailer classroom, Ventura
Beginning Monday, September 30 there will be a weekly meeting on
environments for working with symbolic structures (this includes
programming environments, specification environments, document
preparation environments, ``linguistic workstations,'' and
grammar-development environments). As a part of doing our research,
many of us at CSLI have developed such environments, sometimes as a
matter of careful design, and sometimes by the seat of the pants. In
this meeting we will present to each other what we have done, and also
look at work done elsewhere (both through guest speakers and reading
discussions).
The goal is to look at the design issues that come up in building
environments and to see how they have been approached in a variety of
cases. We are not concerned with the particular details (``pop-up
menus are/aren't better than pull-down menus'') but with more
fundamental problems. For example:
What is the nature of the underlying structure the environment
supports: chunks of text? a data-base of relations? a tree or graph
structure? How is this reflected in the basic mode of operation
for the user?
How does the user understand the relation between objects (and
operations on them) that appear on the visible representation
(screen and/or hardcopy) and the corresponding objects (and
operations) on some kind of underlying structure? How is this
maintained in a situation of multiple presentations (different
views and/or multiple windows)? How is it maintained in the face
of breakdown (system failure or catastrophic user error in the
middle of an edit, transfer, etc.)?
Does the environment deal with a distributed network of storage and
processing devices? If so, does it try to present some kind of
seamless ``information space'' or does it provide a model of
objects and operations that deals with moving things (files,
functions, etc.) from one ``place'' to another, where different
places have relevant different properties (speed of access,
security, shareability, etc.)?
!
Page 4 CSLI Newsletter September 26, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
How is consistency maintained between separate objects that are
conceptually linked (source code and object code, formatter source
and printer-ready files, grammars and parse-structures generated
from them, etc.)? To what extent is this simply left to user
convention, supported by bookkeeping tools, or automated?
What is the model for change of objects over time? This includes
versions, releases, time-stamps, reference dates, change logs,
etc., How is information about temporal and derivational
relationships supported within the system?
What is the structure for coordination of work? How is access to
the structures regulated to prevent ``stepping on each other's
toes,'' to facilitate joint development, to keep track of who needs
to do what when?
Lurking under these are the BIG issues of ontology, epistemology,
representation, and so forth. Hopefully our discussions on a more
down-to-earth level will be guided by a consideration of the larger
picture and will contribute to our understanding of it.
The meeting is open to anyone who wishes to attend. Topics will be
announced in advance in the newsletter. The first meeting will be
devoted to a general discussion of what should be addressed and to
identifying the relevant systems (and corresponding people) within
CSLI, and within the larger (Stanford, Xerox, SRI) communities in
which it exists. --Terry Winograd
←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
``Cree Verb Inflection: Linking Features to Grammatical Functions''
Summary of the meeting on September 12
Cree (Algonquian) is a non-configurational language in which
grammatical functions are encoded by means of a complicated system of
verbal inflection. The verb has ten inflectional affix positions; no
single position is dedicated to a particular grammatical function.
The shape of the person and number affixes is the same for both
subject and object. The task of linking person and number feature
values with the appropriate grammatical function falls to a set of
morphemes traditionally called ``theme signs.''
The talk focussed on the role of the theme signs. Some recent
theoretical accounts have analyzed the theme signs as marking a voice
opposition; on these accounts, the theme signs would be derivational,
rather than inflectional. A subset of the theme signs would mark the
application of a rule like passive, or a rule of ergative relinking,
in which the theme argument is linked to subject, and the agent
argument is linked to object. However, syntactic tests (copying to
object, quantifier float, complement control) show that the passive
and the ergative relinking hypotheses must both be rejected.
In Dahlstrom's analysis, the theme signs are inflectional, acting
as a filter on possible linkings of person and number features to
grammatical functions. The other inflectional affixes carry specific
feature values for person and number, but are unspecified for
grammatical function. Ungrammatical linkings of feature values to
grammatical functions are ruled out by general conditions of
completeness, coherence, and consistency. --Amy Dahlstrom
!
Page 5 CSLI Newsletter September 26, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
NEW CSLI REPORTS
Report No. CSLI-85-31, ``A Formal Theory of Knowledge and Action''
by Robert C. Moore, and Report No. CSLI-85-32, ``Finite State
Morphology: A Review of Koskenniemi'' by Gerald Gazdar, have just been
published. These reports may be obtained by writing to David Brown,
CSLI, Ventura Hall, Stanford, CA 94305 or Brown@SU-CSLI.
-------
∂25-Sep-85 2035 JF@SU-SUSHI.ARPA BATS at Berkeley 10/11/85
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 20:35:49 PDT
Date: Wed 25 Sep 85 20:32:26-PDT
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: BATS at Berkeley 10/11/85
To: aflb.su@SU-SUSHI.ARPA
There will be a BATS (for newcomers, that's Bay Area Theory Seminar) at
Berkeley on Friday, October 11. Please let me (jf@sushi) know:
1) Would you like to speak?
2) Do you need a ride?
3) Can you offer a ride?
4) Would you like to replace me as Stanford BATS coordinator?
Thanks,
Joan
-------
∂26-Sep-85 0059 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #38
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 00:59:17 PDT
Date: Tuesday, September 24, 1985 2:24PM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #38
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Wednesday, 25 Sep 1985 Volume 3 : Issue 38
Today's Topics:
Query - Books-in-print database,
Challenge Problem - Ken Laws,
LP Philosophy - Hewitt's Challenge,
Programming - Building Large Systems,
Implementations - Cut Test & Destructive Assignment,
LP Library - Update
----------------------------------------------------------------------
Date: Mon, 9 Sep 85 10:42 PDT
From: RGARRETT%LAJ.SAINET.MFENET@LLL-MFE.ARPA
Subject: Books-in-print database
I assume you are familiar with "Books in Print" , the multi-volume
listing of most of the books currently in print in the USA. I
would like something similar but on magnetic media;i.e., mag tape
and hopefully cheap. The purpose of this is to serve as the
foundation for an expert system retrieval system to be written in
(what else) PROLOG. Since this is both an experimental system (how
many other kinds of expert systems are there?) and done as a
graduate student, I am only interested in public domain or very low
cost sources. I am already familiar with commercial systems such
as DIALOG and with IRList. I hope this answers your questions, but
if something is still unclear, just drop me a note.
-- Randy Garrett
------------------------------
Date: Thu, 29 Aug 85 10:39:26 pdt
From: Allen VanGelder <avg@diablo>
Subject: Ken Laws' challenge problem
The problem statement assumes some familiarity with image
processing jargon. I am guessing that he is talking about
a 2-dimensional array and that two elements are "connected"
if they are within 1 of each other on both indexes, i.e.,
diagonal adjacency as well as horizontal and vertical
adjacency is connected.
The advantage of a logic-based language, if any, is not to
remove ALL procedural responsibility from the programmer, but
to provide a way to write procedures that have a close enough
connection to the specifications that they can be informally
verified. For example, I can write
neighbor((i,j), (k,l)) :-
not ((i,j) = (k,l)),
adjacent(i, k),
adjacent(j, l).
adjacent(i, j) :-
(i = j; i is j+1; j is i+1).
Note that semi-colon is read "or" and ":-" is read "if" and
comma is read "and". This "procedure" can simply be read in
English as a specification of "neighbor", yet it is also the
Cprolog source code.
Arrays are certainly a problem in logic programming, and Ken's
problem is a good challenge. But he should not expect to see a
naive problem specification that runs as a Prolog program. He
IS entitled to ask for a logic program that is both efficient
and informally verifiable. I don't have that for him.
------------------------------
Date: 05 Sep 85 18:29:55 PDT (Thu)
From: Sanjai Narain <Narain@rand-unix.ARPA>
Subject: Response to Hewitt
>Prolog (like APL before it) will fail as the foundation for
>Artificial Intelligence because of competition with Lisp.
>There are commercially viable Prolog implementations written
>in Lisp but not conversely.
For the same reason, Lisp should have failed as a foundation for
computing because of competition with assembly language.
There are commercially viable implementations of Lisp in assembly
language but not conversely.
>LOGIC as a PROGRAMMING Language will fail as the foundation
>for AI because:
>1. Logical inference cannot be used to infer the decisions
> that need to be taken in open systems because the decisions
> are not determined by system inputs.
>>2. Logic does not cope well with the contradictory knowledge
>> bases inherent in open systems. It leaves out
>> counterarguments and debate.
>>3. Taking action does not fit within the logic paradigm.
1. Hewitt clearly states in his recent BYTE article that
traditionalnotions of computation as defined, for example,
by Turing machines or recursive functions cannot model the behavior
of open systems. Hence even Lisp is inadequate for such modeling
(by his reasoning).
2. The notion of contradiction (i.e. inconsistency) is well
understood in logic.
3. The statement is too vague for debate. What do the words
"action" and"fit" mean? Certainly, if action can be modeled
by an effective procedure, it can be modeled by logic, cf. 1.
-- Sanjai Narain
------------------------------
Date: Thu, 5-Sep-85 13:40:43 PDT
From: (Tom Khabaza) mcvax!ukc!warwick!cvaxa!tomk@Seismo
Subject: On Hewitt's "Prolog and logic programming will fail"
I have read with interest the discussion following Carl Hewitt's
"Prolog will fail as the foundation for AI and so will Logic
Programming". I particularly enjoyed Vijay Saraswat's reply, most
of which I agree with. However, I would like to add a few comments:
In some ways I was surprised by the original message; I should
have thoughtthat if AI has taught us anything, it is that to solve
a given problem, we need a good representation language. Why anyone
might think that logic is the BEST representation language for every
problem is beyond me. (No Kowalskiist flames please, I know the
arguments, and I don't regard the case as proven.)
On the other hand, we don't yet know what the limits of logic
programming are; researchers in the field are constantly coming up
with new techniques. There is convincing evidence that logic
programming is better than conventional programming for some kinds
of task, at least with regard to ease and clarity (though probably
not yet efficiency).
But I think the basis of the original comment goes deeper than the
virtues and vices of logic programming. As I understand it (and I
wasn't around at the time) some earlier AI programming languages,
such as perhaps micro-Planner and its successors, WERE expected to
become a "foundation" for AI. Perhaps this was because people still
had hopes for the notion of some "ultimate" representation language,
or family of languages.
AI is older and perhaps more cynical now; I don't think we expect
some single foundation to the field in the form of a representation
language. Logic programming may be very useful for some parts of
AI; for example some kinds of rule based systems, but I don't expect
it to be the best tool for all kinds of AI programming. In fact my
personal opinion is that logic programming will find its forte in
more conventional Computer Science, where formal specification is a
more practical proposition than in the relatively exploratory
activity of AI programming.
But I will say this in its favour: logic programming is IMPORTANT.
Logic programming is as different from conventional programming as
programming is from not programming at all. I have met people who
have given up on Prolog because it was difficult for them and they
(rightfully) considered themselves competent programmers - and so
thought it must be Prolog's fault! (I don't mean to imply that
anyone who has posted in this discussion is such a person.) But
logic programming is different in fundamental ways; it's worth
presevering to get to the bottom of it, and as logic programming
languages improve, it will become even more so.
So for all you computer people out there, USE Prolog, and study
how other people have used it. It really is worth it.
------------------------------
Date: Tue, 20 Aug 85 21:07:41 EDT
From: Stephen Wolff <steve@BRL.ARPA>
Subject: Another precinct heard from
"Cut test" results for University of York Portable
Prolog, V2.1:
Test
1 2 3 4 5 6
Y Y Y Y Y N
------------------------------
Date: Wed, 28 Aug 85 09:06:26 -0200
From: David McKelvie <mcvax!unido!ecrcvax!david@seismo.CSS.GOV>
Subject: User Interfaces - Building Large Systems
We, the ECRC Man-machine interaction group, have had similar
problems with the slowness of Prolog interpreters for handling
interactive graphics, and have come up with a similar solution.
We have split off the user interface part into a seperate
process (we are using UNIX) and communicate to Prolog via a
pipe, rather than a direct connection to the Prolog database
as you seem to have. However we are having problems in defining
what sort of interface there should be between the UI and Prolog.
Therefore, we would be rather interested in the technical details
of your interface, in particular the Prolog predicates you have
defined, and what you mean by 'object orientedness' ( a horrible
term for a good idea). Does this allow a more declarative than
imperative way of defining pictures from Prolog?
Thank you
-- David Mckelvie
(ECRC stands for European Computer-Industry Research Centre, a
centre funded by European computer companies, mainly doing work
on Logic programming and Knowledge bases. A sort of miniature
version of ICOT or MCC )
------------------------------
Date: Wed, 28 Aug 85 22:32:37 PDT
From: (Rick McGeer) mcgeer%ucbkim@Berkeley
Subject: Destructive assignment
Dedicated hardware isn't magic, you know. You still fill up
space with garbage, and there is no particular reason to believe
that you're going to be able to predict or control where you leave
it. Also keep in mind that if you have a paged virtual memory
system, you experience an enormous degree of internal
fragmentation if your wastage is large and is spread evenly over
more or less half your pages. That's a recipe for thrashing....
The other, major problem with no destructive assignment is time.
If you want to change a small field buried deep inside a large
record, you have to copy the entire record. On interpreted systems
this is not so bad since structure is shared. On compiled systems,
such as Warren & Tick and Berkeley PLM, it's an absolute disaster
because such machines copy rather than share structures. In that
sense compiled code on special-purpose h'ware performs more
poorly than interpreted code on a gp machine.
Some computations are history-sensitive, and that's all there is
to it. Either your programming language recognizes these realities
or it doesn't. If it does, it's useable; if it doesn't, it becomes
a delight for mathematicians and unused by everyone else. Lisp
implementers swallowed hard, gave up purity, and put in setq and
rplacd. Lisp is used and useable. FP and Lucid implementers,
among others, stuck by no-assignment semantics and washed up on
the ash-heap of programming languages. People who implement
Prolog are faced with the same choice, and will face the same
results.
-- Rick
------------------------------
Date: Fri, 30 Aug 85 13:24:56 PDT
From: (Rick McGeer) mcgeer%ucbkim@Berkeley
Subject: Destructive assignment
Here's a good example of when you really need destructive
assignment in Prolog. I'm currently writing an IC layout
expert in Prolog. At one point in the program, nets are
assigned to rows. When this is done, the row's freelist
and wirelist is updated, and so, of course, a new row is
generated.
Now, the difficulty is that the net structure includes the
row that the net runs on. Unfortunately, this row may be
regenerated later with a different freelist. When this happens,
the row pointed to by the net structure disappears from the
list of rows in the grid, so that later processing reports
that the row doesn't exist.
The solution is to keep an (atomic) ID field in each row and
index through that. This both complicates the code and
increases the running time, and obscures what's really going
on.
I might point out that other researchers in this area started
out with Prolog and then went to other languages (eg, C), largely
for these sorts of reasons. Dwight Hill of BTL, who gave a paper
at ICCD '84 on "The Silicon Converter: A Case Study in Uses For
Prolog" has now gone over to C for IC placement and routing.
-- Rick
------------------------------
Date: Fri, 13 Sep 85 01:09:57 edt
From: Tom Blenko <blenko@rochester.arpa>
Subject: Destructive assignment
I agree with your points about the time/memory costs
and difficulties associated with either copying or sharing
data structures.
First point: if you add destructive assignment to PROLOG,
it isn't (even nearly) PROLOG anymore.
Second point: the issues you raise are more clearly critical
for functional languages. I don't agree that FP and LUCID
are washed up on the ash-heap of programming languages: FP
was basically a model for a functional language, not a proposal
for an implementable, production-oriented language. There are
people working quite seriously on the implementation of functional
languages (I am less familiar with serious work on implementation
of declarative languages). I agree that there are as yet no
visible successes, but it is certainly too soon for the jury to
come back in.
We can look at how the LISP machine people addressed the problem
in their design: large VM, large physical memory, cacheing of
everything they could think of, and more recently (not yet released)
garbage collection out of the cache. I don't know the details of
the scheme, but I think it may have been published, and they are
claiming improvement by a factor of two in performance as a result.
I know also of a major computer manufacturer which is implementing
a chip based on SASL. They claim on-the-fly garbage collection,
although emergency (out-of-space) collection is provided.
One performance benefit of functional (and perhaps logic
programming) languages may come in their parallel execution --
specifically that this may be easier to accomplish than for
languages with destructive assignment. I have looked at this
for Concurrent Prolog, and the
write-once property of variables plays a very important role in
reducing the complexity of inter-process communication.
In sum, I agree that there are problems, and I agree that the
solutions are not in hand, but I think it is hasty to conclude
that solutions are not possible, especially since we are really
in the infancy of architectures designed with such languages in
mind.
-- Tom
------------------------------
Date: Sun, 11-Aug-85 19:32:53 PDT
From: ihnp4!houxm!mhuxt!mhuxr!ulysses!burl!clyde!watmath!utzoo
Subject: Supplement to C-Prolog manual, Grammars, Exanmples, etc.
The User's Manual for DEC10 Prolog (circa 1978) had several useful
sections on definite-clause grammars, grammar rules for "Edinburgh"
syntax, example programs, and (early) Prolog references. None of this
information was in the C-Prolog manual distributed with C-Prolog 1.5,
so before our beloved (:-)) TOPS-10 machine vanished into obliv
-ion, I converted these sections into "troff -ms" format to serve as
an appendix to the C-Prolog manual which we distribute to students in
a LP course here. There is no copyright on this material, as far as I
can tell, so I hope F. Pereira & Co. won't mind. I'm postingthe
excerpts to the net, at the suggestion of a colleague. I wouldn't
mind hearing from anyone who found it useful (or who objects to long
articles containing material of ancient vintage); it's hard for me to
gauge whether or not purely pedagogical material such as this should
be circulated on the net.
[ This is available from the SCORE: <Prolog> libray as:
CProlog←Supplementary←Manual.Txt and can be netted over,
if you can't access SCORE: send a request to Prolog-Request -ed ]
------------------------------
End of PROLOG Digest
********************
∂26-Sep-85 0751 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #39
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 07:51:04 PDT
Date: Wednesday, September 25, 1985 4:20AM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #39
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Thursday, 26 Sep 1985 Volume 3 : Issue 39
Today's Topics:
LP Philosophy - Hewitt's Challenge,
Programming - DCGs + Left Recursion,
Implementation - Destructive Assignment,
----------------------------------------------------------------------
Date: Fri, 13 Sep 85 10:41:27 bst
From: William Clocksin <wfc%computer-lab.cambridge.ac.uk@ucl-cs>
Subject: Lisp/Prolog
I received issues 36 and 37 late owing to netproblem somewhere
between Stanford and Cambridge. I am puzzled by this Lisp/Prolog
debate started by Carl Hewitt. I use both Prolog and Lisp, and
have never felt the need to use one exclusively. I suppose they
are like screwdrivers and chisels; both are roughly the same,
but for slightly different purposes; to a person unfamiliar with
one of them, the other one might seem redundant. I am also
puzzled about the question of a "foundation" for AI. How can a
language be a "foundation" for anything? Was Latin a "foundation"
of Western civilisation? Seen any fundamental native speakers
lately? Besides, does AI deserve to have foundations attributed
to it anyway?
Another problem is this question about logic. Prolog is a
programming language. It was inspired by logic, but it is not
programming in logic. Proponents of using logic do have a problem
matching impedance with the real world. But Prolog is to logic
as Lisp is to lambda calculus. Those who advocate programming in
lambda calculus have the same problem as those who advocate
programming in pure logic. If Prolog can be said to have any
connection with logic, it is as the FORTRAN of logic programming.
Prolog is useful because you can grow data structures that have
actual variables in them, and because it is easy to define
nondeterministic methods. I know how Prolog searches for a solution
just as I know how flow of control happens in Lisp, say. I am not
disappointed with Prolog's strict strategy just as I am not
disappointed with Lisp's inability to run programs backwards, say.
I take it as it comes, and it is useful for some things. Talking
hypothetically about the "ideal" language is another topic entirely,
and it only muddies the water to bring Prolog and Lisp into it.
------------------------------
Date: Fri, 13 Sep 85 10:07:09 bst
From: William Clocksin <wfc%computer-lab.cambridge.ac.uk@ucl-cs>
Subject: Prolog on/in Lisp
Compiling Prolog into Lisp is one way to provide a fast
Prolog/Lisp. A student did this as a project last year;
no doubt it has been done elsewhere. The Warren New Engine was
used as a model. The compiler, took Prolog procedures and
generated Lisp code in a mixture of procedure calls and macros.
The clever part was getting backtracking right. This was then
compiled into IBM machine code, and run on a 3081. It was not
fast, owing probably to the large size of code body. I forget
how slow, say 10KLIPS or so. The final speed was not important
for the goals of the project. More important was finding out
what special provision could be made in the future (in the form
of Prolog-specific support) to provide a more efficient system.
Also, it was the student's very first Lisp program, so hhe can be
forgiven for doing a few extremely inefficient things.
------------------------------
Date: Thu, 19 Sep 85 16:15:07 PDT
From: Adolfo Di-Mare <dimare@LOCUS.UCLA>
Subject: DCGs + Left Recursion = (:-[) !
I'm writing a little parser for a Pascal like language.
I was going to copy Wirth's grammar into a DCG Prolog
program, but I noticed that left recursion can't be used.
If you have a rule like:
a --> a, [+], b. a --> b. b --> [b].
it translates into:
a(A, B) :- a(A, C), 'C'(C, +, D), b(D, B). 'C'([H|T],H,T).
Any goal of the form a(Sentence,[]) would make the above
rule recurse until end←of←stack.
(Yes, a([b,+,b],[]) doesn't work either: try it!).
My problem is that the grammars I know for parsing expressions
are left recursive. The example in most Prolog manuals uses left
recursion. I ran it, and I got the following result (I include
the code at the end of the message):
| ?- expr(Z,"2-3-4",[]).
Z = 3 ;
no
| ?- Z is 2-3-4.
Z = -5 ;
no
| ?- halt.
Obviously, the 'standard' example is wrong. My question is: Does
any body know a way to do expressions using DCGs that doesn't make
the grammar look like a plate of spaghetti? I know I could translate
my grammar into Griebach Normal Form (or $%#!"%#$" Normal Form, for
that mater), but I could also as well write the whole parser in
8080 assembly language. Here's the grammar:
Script started on Thu Sep 19 15:16:07 1985
h[2:101] c dcg0
% File : /usr/lib/prolog/teach/dcg0
% Author : lost in the mists of time
% Updated: 23 Nov 1983
% Purpose: the standard example of using Prolog grammar rules
% This is a simple grammar which parses an arithmetic expression (of
% digits and operators) and computes its value.
expr(Z) --> term(X), "+", expr(Y), {Z is X+Y}.
expr(Z) --> term(X), "-", expr(Y), {Z is X-Y}.
expr(Z) --> term(Z).
term(Z) --> number(X), "*", term(Y), {Z is X*Y}.
term(Z) --> number(X), "/", term(Y), {Z is X/Y}.
term(Z) --> number(Z).
number(C) --> "+", number(C).
number(C) --> "-", number(X), {C is -X}.
number(X) --> [C], {48=<C, C=<57, X is C-48}.
% In the last rule, C is the ASCII code of a digit.
% The question
%
% | ?- expr(Z,"-2+3*5+1",[]).
%
% will compute Z=14. The two extra arguments here are because
% grammar rules are in fact merely 'syntactic sugar' for ordinary
% Prolog clauses. Each grammar rule takes an input string, analyses
% some initial portion and produces an output portion (the rest,
% possibly enlarged a bit) for further analysis.
h[2:102] uprolog
CProlog version 1.4d.edai
| ?- [dcg0].
dcg0 consulted 1208 bytes 0.78333 sec.
yes
| ?- expr(Z,"2-3-4",[]).
Z = 3 ;
no
| ?- Z is 2-3-4.
Z = -5 ;
no
| ?- halt.
[ Prolog execution halted ]
h[2:103]
script done on Thu Sep 19 15:18:16 1985
------------------------------
Date: Mon, 16 Sep 85 10:26:55 PDT
From: (Rick McGeer) Mcgeer%ucbkim@Berkeley
Subject: Destructive assignment
I would be extremely surprised if you could get away
without destructive assignment. In addition to the other points
I've raised, consider this: many large programs consist of networked
data structures: that is, some data structure (say A) may be a
substructure of structures (B, C, and D). If the only way to modify
A is to create a new structure, A', then the code that modifies A to
produce A' must also create B', C', and D', and so forth recursively.
Now, it's almost impossible to write modular code in such a
situation: the internals of each data structure in such a network
must be apparent to the code which modifies the leaf structures in
the network, or else the network becomes inconsistent.
This sort of problem creeps up all the time in NL understanding
programs, VLSI layout programs, and algorithm-based algebra programs.
To my knowledge, only toy systems have been written in these areas in
Prolog. Both Dwight Hill at Bell Labs and I have independently tried
to write a real layout program in Prolog, but the mechanics of moving
the data structures around and ensuring that the ds network remains
consistent have forced him to abandon his attempt (and write in C):
I have been forced into a reappraisal.
I agree, if it were merely a matter of efficiency then we
could hope for hardware to work its magic. But it's a matter of
sofware engineering, aswell. A language ultimately stands or falls
on its software engineering aspects and not on its semantics (which
are only important to implementers and, to a minor extent, in
ergonomics). I am afraid that Prolog currently does not support
good software engineering techniques, and in fact makes some
software engineering techniques (modularity, data abstraction)
impossible. Unless and until it supports those techniques at least
to the extent that Lisp does, Prolog is a toy language.
-- Rick.
------------------------------
Date: Mon, 23-Sep-85 07:40:31 PDT
From: Vantreeck%logic.DEC@DECWRL.ARPA
Subject: DCGs + Left Recursion = (:-[) !
You are correct in your assertion that most PROLOGs'
DCGs do not handle left recursion. That's because they're
simple top down parsers. There is a PROLOG DCG parser that
uses bottom up parsing (and can handle left recursions).
The parser is called BUP. Need I say it stands for Bottom
Up Parser?
I don't have the references here at work - the papers
are a couple of years old. I'm sure your UCLA libarary can
do a computer search on BUP. Off the top of my head -- A
brief description can be found in a book by Dahl, Natural
Language Understanding with Logic - it's a collection of
papers from a 1984 symposium in France.
The articles I've read on BUP tend to be of the "Gee,
isn't this wonderful!" variety, rather than delving into
enough implementation detail that someone could use it as a
guide to writing a BUP. If anyone finds a paper that gives
an in depth description of the implementation details,
please post it to the net!
-- George
------------------------------
End of PROLOG Digest
********************
∂26-Sep-85 1048 @SU-SUSHI.ARPA:MAYR@SU-SCORE.ARPA talk by Marc Snir
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 10:44:56 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 26 Sep 85 10:38:14-PDT
Date: Thu 26 Sep 85 10:18:47-PDT
From: Ernst W. Mayr <MAYR@SU-SCORE.ARPA>
Subject: talk by Marc Snir
To: su-bboards@SU-SCORE.ARPA, aflb.su@SU-SCORE.ARPA
Message-ID: <12146369201.9.MAYR@SU-SCORE.ARPA>
Seminar Announcement
Software Issues in the Design of Shared Memory MIMD Software
Speaker: Marc Snir
Location: MJH352
Time: Tuesday, Oct. 1, at 1:00pm
Abstract: The NYU Ultracomputer and the IBM RP3 machines are MIMD shared
memory parallel machines. Processors are connected to global memory by a
global packet switched inter-connection network; the network is actively
involved in processing.
These machines pay the cost of a complex interconnnction network in order
to avoid the burden of explicit resource allocation by the user. They are
intended to provide a close approximation to an ideal model of computation,
where accesses to shared memory are atomic, and can be concurrently done by
all processors.
In reality memory accesses are not atomic, and resource allocation overheads
cannot be ignored. The gap between the ideal model and the machine reality
can be narrowed by a mixture of compile time and run time optimization
techniques, and by new hardware structures.
We shall survey some specific problems and some of the techniques that can
be used to soften their impact. How to schedule memory accesses so that
resulting code is serializable.
How to provide atomic access to structures.
How to cache or prefetch shared data.
How to avoid excessive process fragmentation.
How to synchronize.
-------
∂26-Sep-85 1539 NEUMANN@SRI-CSLA.ARPA RISKS-1.16
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 15:38:26 PDT
Date: Thu 26 Sep 85 13:33:02-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.16
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-LIST: RISKS-FORUM Digest Thursday, 26 Sep 1985 Volume 1 : Issue 16
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Intellectual honesty and the SDI (Bill Anderson)
RISKy Stuff (Mike Padlipsky)
Mailer Protocol Woes (Rob Austein)
Risks in Synchronizing Network Clocks (Ann Westine for Jon Postel)
Re: Moral vs. Technological Progress (Joel Upchurch)
Risk Contingency Planning -- Computers in Mexico (Mike McLaughlin)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions must
be relevant to the topic, objective, in good taste, and coherent. Others
will be rejected. Please try to advance the discourse, rather than iterating
and reiterating. There is no fine line between what is acceptable and what
is not, and thus the moderator's decisions may occasionally seem arbitrary.
It is our clear intent to represent a diversity of views. However, we
cannot be expected to provide counterarguments when none are forthcoming.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: 18 Sep 85 15:48 EDT
From: WAnderson.wbst@Xerox.ARPA
Subject: Intellectual honesty and the SDI
Courtesy-of: minow%rex.DEC@decwrl.ARPA (Martin Minow, DECtalk Engineering)
FROM AIList Digest Friday, 20 Sep 1985 Volume 3 : Issue 125
At the recent IJCAI at UCLA I picked up a couple of papers at the GE
exhibit booth. One of these, entitled "A Tutorial on Expert Systems
for Battlefield Applications," (delivered at a meeting of the Armed
Forces Communications and Electronics Association last May) states that
"AI systems that incorporate human expertise may be the only way" to
fill the gap between availability of people and complexity of military
hardware. In defense of this strategy the author states:
- In contrast with humans, AI systems are good at handling the myriad
details of complex situations, such as often occur in military settings.
- In contrast with other computational approaches that are more formal
and algorithmic, AI systems are more robust: they are designed to deal
with problems exhibiting uncertainty, ambiguity, and inaccuracy.
I find it appalling (and frightening) that statements like this can be
presented in a technical paper to military personnel. The author
(according to the references) has contributed widely to the AI field at
many conferences. It's simply ludicrous to state that current AI systems
are better in battlefield situations than humans. What was the last AI
system that could drive a tank, carry on a conversation, and fix a
broken radio whilst under enemy fire? The second comment is equally
misleading. To contrast "formal and algorithmic" with "robust" seems
to imply that algorithms and formal procedures are inherently not
robust. On what is this claim based? (There is no reference attached
to either statement.) It sounds like a recipe for unreliable software
to me.
How can someone write this stuff? I know, to make money. But if this
is the kind of information that is presented to the military, and upon
which they make decisions, then how can we expect any kind of fair
assessment of the possible projects in the Strategic Computing (and
Defense) Initiatives? How can this kind of misinformation be rebutted?
Bill Anderson
P.S. The full reference is available on request.
------------------------------
Date: 20 Sep 1985 18:33:30 EDT
From: PADLIPSKY@USC-ISI.ARPA
Subject: RISKy Stuff
To: neumann@SRI-CSL.ARPA
... I suppose I might as well succumb to temptation and offer a couple
of comments on stuffgoneby:
The most striking omission, to my mind, in the SDI discussion is (unless I
missed spotting it) the failure to draw the parallel to SAGE. For those who
don't remember/know, the Semi-Automated Ground Environment was the
grandfather of the big, "man-machine" system, certainly in DoD and most
probably in the field as a whole. It was intended to allow for the
interception of manned bombers. It is widely acknowledged to have spun off
a lot of what became the state of our art (collective art, that is-- i.e.,
what I call the computer racket). Like SAGE, SDI is probably dealing with
the wrong threat (since things don't have to go through the air to go boom
... and since things don't even have to go boom to rack up megadeaths).
Also like SAGE, SDI might have useful spinoffs (a 20-years-younger colleague
claims to be for it because it should help get him off this planet).
Unfortunately, unlike SAGE it seems to possess a real potential for
stampeding the presumed Bad Guys into doing something ... unfortunate.
What a good thing we Men of Science know better than to reason
from analogy, eh?
... muted cheers, map
------------------------------
Date: Fri, 20 Sep 1985 14:36 EDT
From: Rob Austein <SRA@MIT-XX.ARPA>
To: mooremj@EGLIN-VAX
Cc: neumann@sri-csla
Subject: Mailer Protocol Woes
I was actually a culprit in a similar mailer lossage earlier this
week. The whole thing actually started out when I was dialed up to XX
on a noisy connection. Improbable as it seems (although not quite on
the order of monkeys and Shakespeare), the random line noise managed
to generate the 7 character command sequence necessary to send off my
entire mail file as a single message to a major mailing list. All 110
pages (=281600 bytes) worth of it. Fortunately for the network (but
unfortunately for my reputation) the list happened to be the TOPS-20
maintainers' mailing list, so the message got killed off in pretty
short order. I have since put in a couple of safeguards into my mail
reader environment so that this particular lossage can't happen again,
but since the real culprit was transmission line noise I have been
kind of nervous about reading my mail over dialups ever since....
--Rob
------------------------------
Date: 25 Sep 1985 09:07:47 PDT
Subject: Risks in Synchronizing Network Clocks (RFC956 Now Available)
From: Ann Westine <WESTINE@USC-ISIB.ARPA>
Plucked-From: Request-For-Comments-List: ;
A new Request for Comments is now available from the Network Information
Center in the <RFC> directory at SRI-NIC.ARPA.
RFC 956:
Title: Algorithms for Synchronizing Network Clocks
Author: D. L. Mills
Mailbox: Mills@USC-ISID.ARPA
Pages: 26
Characters: 68868
pathname: <RFC>RFC956.TXT
This RFC discussed clock synchronization algorithms for the
ARPA-Internet community, and requests discussion and suggestions for
improvements. The recent interest within the Internet community in
determining accurate time from a set of mutually suspicious network
clocks has been prompted by several occasions in which errors were
found in usually reliable, accurate clock servers after thunderstorms
which disrupted their power supply. To these sources of error should
be added those due to malfunctioning hardware, defective software and
operator mistakes, as well as random errors in the mechanism used to
set and synchronize clocks. This report suggests a stochastic model
and algorithms for computing a good estimator from time-offset
samples measured between clocks connected via network links.
Included in this report are descriptions of certain experiments which
give an indication of the effectiveness of the algorithms.
Distribution of this memo is unlimited.
Public access files may be copied from the <RFC> directory at
SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST.
The normal method for distribution of RFCs is for interested parties
to copy the documents from the NIC online library using FTP.
Requests for special distribution should be addressed to either the
author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA.
Requests to be added to or deleted from this distribution list should be
sent to NIC@SRI-NIC.ARPA.
--jon.
[I include this item in the RISKS Forum for a very obvious reason:
one of the nastiest of all problems in distributed computer systems
and networks is the synchronization problem. That so many
seemingly correct algorithms have in fact been flawed is a very
important consideration here. PGN]
------------------------------
Date: Wednesday, 25 Sep 1985 16:27-EDT
To: risks@sri-csl.arpa
Subject: Re: Moral vs. Technological Progress
X-From: joel@peora.UUCP (Joel Upchurch)
>Actually McCarthy's original comment presupposes that moral and
>technological progress are comparable. It is that assumption that I
>disagree with. Ethics and the attendant morality provide the context
>within which all activity, and in particular technological progress,
>exists. Morality and technology are not substitutes for one another
>and moral progress is not dependent on technology nor vice versa.
>There is always technological progress attendant to moral progress
>just because there is always technological progress.
I don't think that there is any such thing as an absolute moral standard.
Morality is simply a set of customs that evolves by trial and error to
improve the survival chances of the social group (family, tribe, nation
whatever). Notice that this has has little to do individual survival and
that a moral principle, such as patriotism, may cause the individual to get
killed.
Now I think it fairly easy to see that the capacity to put group survival
ahead of self-interest is an important genetic trait and that tribes of
people that had this trait would be more likely to survive that tribes that
didn't. That is not to say that this moral capacity doesn't vary greatly
from one person to the next or that even that it may not be more fully
realized in one person than another because of upbringing. It is even
possible that, because of some genetic error, some people may be born
without a moral capacity, just like they might be born without arms or legs.
The point I'm trying to make is although there will always be these survival
customs we call morality, the nature of the customs is heavily dependent on
the context they evolve in. Thus the morals of a herding society may be
greatly different from those of an agrarian one. Even two societies in
similar contexts may evolve different moral solutions to the same problems.
This implies that if the context in which a society operates changes, then
the morals of that society will have to change too. In recent centuries the
most important changes in the social context have been caused by technology.
Thus the morals appropriate to a agrarian society are not always appropriate
to an industrial one or those of an industrial society to a post-industrial
one.
Moral progress means the evolution of survival customs more appropriate to
the current context. The trouble in recent centuries has been that our
ability to evolve new technology has outstripped our capacity to evolve the
appropriate morality for it. There is a strong tendency to stick to the
morality that one learns as a child, even if it not appropriate to the
current situation.
Our current problem is that we have a technology that supplies us with ICBMs
and a morality that includes national patriotism. Now it is obvious to any
thinking person that this is a serious dilemma. Some people argue that we
should adopt a new morality, more appropriate to this technology, and indeed
in the long term they are correct, although one can argue what is the most
effective moral solution to this problem.
The trouble is that moral solutions evolve slowly. Even today much of our
morality is left over from our nomadic and agrarian heritage and has limited
relevance in our modern society. In order to apply the long term solution,
we must first survive in the short term, and in that short term technical
band-aids, like the SDI, are appropriate. Technology put us into this
situation and I don't see why we can't ask technology to assist us in the
solution. To think that we can solve the problem by an overnight revolution
in human nature is wishful thinking of the most dangerous sort.
Joel Upchurch
Perkin-Elmer Southern Development Center
2486 Sand Lake Road/ Orlando, Florida 32809/ (305)850-1031
{decvax!ucf-cs, ihnp4!pesnta, vax135!petsd}!peora!joel
------------------------------
Date: Sat, 21 Sep 85 13:25:25 edt
From: mikemcl@nrl-csr (Mike McLaughlin)
To: risks@sri-csl.ARPA
Subject: Risk Contingency Planning -- Computers in Mexico
This is not info, but a call for info. I have no idea how bad the computer
bug has bit in Mexico, but the current news & TV coverage of the disaster
suggest that whatever computing/networking is going on must have been
affected. If any RISKS reader knows some statistics or details about
computer usage in Mexico, and can give insights as to what happened, what
backup and alternative modes were in place, how well they worked... etc. It
would certainly help me, and perhaps many others in planning for the
disaster that we hope never comes. Perhaps we could discuss just what we
want to find out, and then go after the answers formally, if there are no
informal contacts on the net. - Mike
[This item may seem a little odd for the RISKS Forum, but when you
realize that Mike's Navy job involves expecting the unexpected risks
in computer and network usage, and planning what to do, it is indeed
relevant. By the way, in Mexico, as usual in times of disaster, the
ham-radio buffs lept in to help. Computer networks and internets
also have a role to play. I'm ready with my battery-operated
portable terminal. (This issue is being sent from DC.) PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂26-Sep-85 1704 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Monday's PLANLUNCH
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 17:04:28 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Thu 26 Sep 85 16:59:56-PDT
Date: Thu 26 Sep 85 16:58:54-PDT
From: LANSKY@SRI-AI.ARPA
Subject: Monday's PLANLUNCH
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, phayes@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
araya@XEROX.ARPA, frayman@XEROX.ARPA, suchman@XEROX.ARPA, weld@XEROX.ARPA,
mittal@XEROX.ARPA, dekleer@XEROX.ARPA, trigg@XEROX.ARPA
PROCESSES, SIMULTANEITY AND CAUSALITY
Michael P. Georgeff
Artificial Intelligence Center
SRI International
11:00 AM, MONDAY, September 30
SRI International, Building E, Room EJ228 (new conference room)
The notion of process is essential for reasoning about the behavior of
multiple agents or single agents in dynamic worlds. In this talk, we
show why reasoning about process is so important, and contrast this
with other approaches in AI which are primarily based on the allowable
behaviors of agents. An algebra of processes based on events is given.
We then show how events can be represented as changes of world state,
and how state properties can be inferred from the model. Interestingly,
no STRIPS-like assumption is involved in the definition of events, thus
allowing a proper model-theoretic semantics. One of the most important
features of the model is a hiding operation. This provides an abstraction
capability that can be used to avoid the combinatorial explosion
typical of other AI approaches. Finally, we introduce a notion of
causality between events and processes. This, together with the
notion of simultaneous actions and hiding operations, allows us to
avoid most of the problems associated with the frame problem.
-------
∂26-Sep-85 2229 sinha%gmr.csnet@CSNET-RELAY.ARPA add sinha@gmr to NAIL
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 22:29:41 PDT
Received: from CSNET-RELAY.ARPA by su-aimvax.arpa with Sendmail; Thu, 26 Sep 85 22:29:01 pdt
Received: from gmr by csnet-relay.csnet id ai17481; 26 Sep 85 10:26 EDT
Date: Wed, 25 Sep 85 21:43 EST
From: Sarvajit←Sinha <sinha%gmr.csnet@CSNET-RELAY.ARPA>
To: nail@su-aimvax.ARPA
Subject: add sinha@gmr to NAIL
∂27-Sep-85 0153 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #40
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 27 Sep 85 01:53:39 PDT
Date: Thursday, September 26, 1985 10:46PM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #40
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Friday, 27 Sep 1985 Volume 3 : Issue 40
Today's Topics:
Implementation - Destructive Assignment,
LP Philosophy - Hewitt's Challenge,
LP Library - Benchmarks
----------------------------------------------------------------------
Date: 26 Sep 85 8:35:05 PDT
From: Deutsch.PA@Xerox.ARPA
Subject: Destructive Assignment
With regard to destructive assignment: I am constantly amazed at how
people who appear to know little about the last 20 years of
language/compiler implementation technology make statements about
"language X is intrinsically inefficient". Even today, the amount of
compiler technology invested in Lisp is miniscule compared to Fortran.
Why?? I think it is because sub-field specialization in CS has gotten
to the point where almost no one in the Lisp/AI sub-field studies the
optimizing compiler sub-field. Look at what David Warren's compilers
did for Prolog!
Specifically with regard to the assertion that "applicative languages
are horrendously inefficient because they have to copy all the time":
static analysis, not much more subtle than performed by current
optimizing compilers, can identify patterns of sharing, and can result
in compiled code that implements the semantics of the source program
by updating in place in many cases. Sometimes this can even be done
dynamically with reference counts -- the overhead of reference
counting is well documented at around 10% using deferred reference
counting for stack frames (also known as Deutsch/Bobrow reference
counting), climbing to around 50% if you count everything.
There is a real chicken-and-egg problem here: people think
applicative languages are inefficient, so they don't take them
seriously, so the work doesn't get done that would produce the
efficient implementations that would lead people to take them
seriously!
------------------------------
Date: Wed 25 Sep 85 11:22:32-PDT
From: Fernando Pereira <PEREIRA%sri-candide@sri-marvin>
Subject: Prolog vs. Lisp (again!)
I humbly confess my incompetence at the debating style Carl
Hewitt is using in the Prolog vs. Lisp discussions, which
seems to consist in ignoring the FACTUAL points of other
contributions and just continuing to repeat the same OPINIONS.
It is a FACT that no practical Prolog system is written entirely
in Lisp: Common, Inter or any other. Fast Prolog systems have
been written for Lisp machines (Symbolics, Xerox, LMI) but their
performance depends crucially on major microcode support (so
much so that the Symbolics implementation, for example, requires
additional microstore hardware to run Prolog). The reason for
this is simple: No Lisp (nor C, for that matter...) provides the
low-level tagged-pointer and stack operations that are critical
to Prolog performance.
The fact that Lisp is not good enough as an implementation
language for Prolog should not be considered as a weakness of Lisp,
BECAUSE Lisp was not designed for such low-level operations in the
first place. In fact, NO ``high-level'' programming language that I
know of provides those kinds of operations, and for the very simple
reason that, being high-level languages, they have no business in
exploring the recesses of particular machine architectures. ALL
fast Prolog systems that I have seen (some of which I helped
implement) rely on a careful exploitation of the underlying machine
architecture.
By the same argument, the fact that Lisp cannot be efficiently
implemented in Prolog cannot be the basis of a valid criticism of
Prolog. Prolog is not a systems programming language, and in any
case a good Lisp implementation must be carefully coupled to the
underlying machine architecture -- so much so the the fastest Lisps
rely on specialized architectures!
It seems clear to me that no single existing programming language
can be said to provide a ``foundation'' for AI. In fact, the very
notion of a programming language providing a foundation for a
scientific subject seems to me rather misguided. Does Fortran
provide a ``foundation'' for physics? The relation between AI
problems, formal descriptions and programming concepts is far too
subtle for us to expect a ``foundation'' for AI in a mere
programming language.
The crusading tone of Hewitt's comments is also rather
unsettling. AI researchers will use whatever language they
feel most comfortable with for the problem they are working
on, without need for any guidance from on high as to the
ultimate suitability of that language. If more researchers use
Prolog, is that a threat to Lisp users? If I do a piece of AI
research using Prolog, will it not be judged according to its
content, independently of programming language?
That kind of battle might be very important for AI software
companies, but surely we should not let marketing hype get in
the way of our research. I am sitting at a Sun workstation typing
this, with a Prolog window just to the right. Will my research be
useless to someone who sits at a Xerox 1109? If I walk down the
corridor and write a Lisp program on a Symbolics machine (as I
have done and surely will continue to do), will THAT work have
a different value? If I decide to use Hoare's CSP for the
navigation component of our robot Flakey, will I be then outside
AI, because I am not using an ``official'' AI language?
With respect to Rick McGeer's points: there are some elegant ways
of compiling Prolog into Lisp, particularly into those statically
scoped variety (or into other statically-scoped languages such as
Algol-68...). I have reason to believe that a compiler along these
lines would produce code considerably faster than the 100 LIPS he
reports, even though still much slower than what is attainable with
a lower-level implementation.
The idea has been around in the ``folklore'' for a long time, I do
not know to whom to attribute it. Basically, given predicate
definitions like
p :- q, r.
p :- s.
q.
we get the code
(defun p (continuation)
(progn
(q (function (lambda () (r continuation))))
(s continuation)
)
)
(defun q (continuation)
(funcall continuation)
)
This is the basic control skeleton, extra code is needed for
unification. This technique can be made more complicated (and
more efficient...) in a number of ways, and it will be somewhat
more space-efficient on a tail-recursive Lisp.
As to the speed of Franz, if all the appropriate compilation
flags are used an append function written in Lisp runs at
around 25K calls/sec. on a VAX 780, if I remember correctly.
The lower speed he listed is the result of using the (default)
slow function-calling protocol that allows breaks and stack
backtraces. As a comparison, one of the commercial compiled
Prologs does 23K calls/sec. on the equivalent test.
-- Fernando Pereira
------------------------------
Date: Wed 25 Sep 85 11:34:13-PDT
From: Fernando Pereira <PEREIRA%sri-candide@sri-marvin>
Subject: My original rebuttal of Hewitt's flame
Some combination of Carl's and editing has made it impossible
to distinguish in his message what I said and his comments on
what I said. Here is my original note, which I sent only to
the AIList, where the discussion had migrated from COG-SCI
(which I don't read, time being limited...)
Carl Hewitt's message is based on several misconceptions:
1. (the least interesting one) All the so-called commercially
viable Prolog systems in Lisp are not really Prolog systems
written IN Lisp, but rather Prolog systems written FOR Lisp
machines. Or is it that a microcode sublanguage or Lisp machine
pointer-smashing operations are part of List as we know it? Without
those machine-level operations, those Prolog systems would run too
slow and use too much memory to be useful for serious Prolog
programming. From the Prolog implementation point of view, what
is important about the Lisp machines is not that they run Lisp,
but that they can be microcoded and have good support for tagged
data types and stack operations.
2. If the decisions (actions) of a system are not determined by
its inputs, the system is nondeterministic. Nondeterminism in a
system can be either an artifact of our incomplete knowledge (or
lack of interest) of the detailed operation of the system; or it
can be ``real physical'' nondeterminism. It would take us to far
to discuss whether the second kind of nondeterminism is ``real''
or also an artifact. In any case, most uses of nondeterminism,
say in models of concurrency, are of the first kind, and can be
expressed appropriately in various temporal/dynamic logics.
Admittedly, these are not Prolog, but then Common Lisp is not Lisp
1.5! (Prolog is 13 years old, Lisp 25).
3. The first logic course dictum ``from a contradiction one can
conclude anything'' is getting in the way. Notice that the dictum
says ``can'', not ``must''. There is an enormous difference between
things that are in principle true and things that an agent knows to
be true in a way that can affect its action. An agent might know
``p'' and ``not p'', but it might well never come to infer the
dreaded totally unrelated ``q'' which IN PRINCIPLE follows from
the contradiction. This inference might not happen either because
of inference control mechanisms of the agent (eg. it uses the set
-of-support strategy) or because the agent's logic is just TOO WEAK
to conclude anything from a contradiction (vide Hector Levesque's
work in the proceedings of the last AAAI). In any case, Horn clauses
(the basis of Prolog) are too weak to represent contradictions... :-)
4. The question of whether ``taking action'' fits in a logic paradigm
tends to be answered negatively after an hour's worth of
consideration. If you persist for several years, though, this
question becomes a source of insight on the relations between
knowledge, state and action that is not available to those who started
by dismissing the question after that initial hour. There is just too
much work on logics of knowledge and action in AI and computer science
for me to try to discuss it here. Some of this work has been applied
to logic programming, either in the form of new logic programming
languages based on temporal or dynamic logics or in representations of
temporal reasoning and decision in, say, Prolog.
5. It is curious to see someone by implication defend Lisp as a
language for expressing the taking of action! We know by now that the
most difficult issue in ``reactive systems'' is not EXPRESSING action,
but rather keeping it under control to prevent unwanted interactions.
In this area, less is REALLY more, and highly complex languages like
Lisp are just not suitable for the formal reasoning about programs
that is needed to help us believe our programs do what we intend. To
those who say ``...but we can keep to a carefully constrained subset
of Lisp, use only message passing for interactions,...'' I will answer
that the history of all large Lisp programs I know (and I think that
is a representative sample) is littered with the brutalized corpses of
constrained programming styles. Anyone who has looked at the current
flavor mechanism in Zetalisp and its use in the window system will
know what I mean...
6. Underlying Carl Hewitt's misconceptions is the old chestnut ``logic
is static, systems are dynamic''. Any language, be it first-order
logic or Lisp, is static; it is its USE which is dynamic (changes the
state of communicating agents). A good analogy here is the use of
differential equations to model dynamic systems in classical
mechanics. The differential equations themselves do not say directly
what happens when (they are ``static'' in Hewitt's jargon). It is
their SOLUTIONS that tell us the sequence of events. Even the
solutions are given as static objects (functions from an open interval
of the reals to some space). Does anyone worry that such equations do
not ``really'' describe the dynamic behavior of a system? Is it not
possible to combine such ``static'' entities with an incremental
solution procedure to build systems that actually control their
(classical mechanical) environment?
-- Fernando Pereira
------------------------------
Date: Tue, 24 Sep 85 09:43:30 edt
From: "Bruce T. Smith" <bts%mcnc.csnet@CSNET-RELAY>
Subject: A set of PROLOG benchmarks...
I received the following file late in the Summer, with permission
to post it to the net. It's a set of Prolog benchmarks, by folks
at Tektronix and Portland State University. The times included
are for C-Prolog on a Tektronix Magnolia-- as I understand it, a
predecessor of the 4404.
I've run them-- with minor changes-- with Quintus Prolog, on a VAX
785 at MCNC, and with C-Prolog, UNSW Prolog and MU-Prolog at UNC
Chapel Hill, also on a 785. (Both running 4.2bsd UNIX.) For those
folks with other Prologs or other machines, I will volunteer to
collect the results you mail and post a summary to the net later
in the Fall.
I'd also like to hear comments on the benchmarks themselves. For
that, a discussion on the net is more appropriate.
[ I've left this file in the <Prolog> directory as:
TEKTRONIX←PSU-BENCHMARK.PL -ed ]
------------------------------
End of PROLOG Digest
********************
∂27-Sep-85 0902 NEUMANN@SRI-CSLA.ARPA RISKS-1.17
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 27 Sep 85 09:01:49 PDT
Date: Fri 27 Sep 85 07:51:56-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.17
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-LIST: RISKS-FORUM Digest Friday, 27 Sep 1985 Volume 1 : Issue 17
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
SDI debate announcement
Minor risk to the pocket book (Eugene Miya)
Social Impacts of Computing: Graduate Study at UC-Irvine (Rob Kling)
Friendly enemy test teams (John Mashey)
More protocol goofs (Dave Curry)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions should
be relevant to the topic, technically sound, objective, in good taste, and
coherent. Others will be rejected. Diversity of viewpoints is welcome.
Please try to avoid repetition of earlier discussions.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: 26 Sep 1985 17:48-EST
From: genrad!teddy!lkk@mit-eddie.MIT.EDU
Subject: SDI debate announcement
To: risks@sri-csl.arpa
Dear Colleague,
Computer technology plays an ever-increasing role in the arms race.
The Strategic Defense Initiative (`Star Wars') is a leading example
of a military system in which almost complete reliance will be placed
on computerized decision making. The feasibility and desirability of
this system are currently undergoing serious public debate.
On Monday, the 21st of October, at 8:00 pm in M.I.T.'s Kresge Auditorium, the
M.I.T. Laboratory for Computer Science and Computer Professionals for Social
Responsibility are co-sponsoring a public forum designed to raise many of the
technical issues surrounding the Strategic Defense Initiative (SDI).
Professor Michael Dertouzos, Director of the M.I.T. Laboratory for Computer
Science, will moderate a debate on the feasibility of software development
for the SDI project. Dr. Danny Cohen (Director of the Systems Division at
the University of Southern California's Information Sciences Institute and
Chairman of the Strategic Defense Initiative Organization panel on Computing
in Support of Battle Management (SDIO/CSBM)) and Professor Charles Seitz
(Professor of Computer Science, California Institute of Technology and
member, SDIO/CSBM)) will speak in favor of the SDI proposal. Professor
David Parnas (Lansdowne Professor of Computer Science, University of
Victoria, Canada) and Professor Joseph Weizenbaum (Professor of Computer
Science, Massachussetts Institute of Technology) will take the position that
such a software development project is infeasible.
Professor Parnas' resignation from the SDIO/CSBM panel in June of
this year, and the set of memos he wrote discussing the infeasibility
of the SDI project attracted extensive press coverage in June of this
year.
CPSR will be holding a reception for the speakers at La Groceria (853
Main Street in Cambridge) between 6:30 and 7:30. Please join us for
dinner and an opportunity to meet some of the panelists. The $25 per
plate donation will help us cover expenses for this forum and related
projects. Please RSVP to Mark Vilain at (617) 648-4325.
Earlier that afternoon, the M.I.T. Technology and Culture Seminar
will sponsor a talk by Dr. James Ionson, Director of the Office of
Innovative Science and Technology for the SDIO. After Dr. Ionson
describes the general research goals of SDI, two M.I.T. professors
will respond with varying views on why they have chosen to accept or
refuse funding for research from the SDIO. A student representative
will report on student reaction to Star Wars projects on campus.
This talk will be held at MIT in building 9, room 150 at 4:00 p.m.
------------------------------
From: eugene@AMES-NAS.ARPA (Eugene Miya)
Date: 26 Sep 1985 1652-PDT (Thursday)
To: risks@sri-csl.ARPA
Subject: Minor risk to the pocket book
Here is a minor man-machine risk which occurred today (9/26) in the Silicon
Valley at El Torito [popular Mexician food chain] at lunch. We arrived for
a late lunch and found that our bill was 50% over what appeared in the menu.
The cash register [one of those computer systems where they press buttons
rather than prices] was running on the dinner menu prices rather than the
lunch menu prices. Since we arrived late, everybody else [e.g., hundreds of
people] were over-charged for lunch that day and perhaps earlier. This
implies several things about the way customers in Si Valley treat their
bills [rich? no verification? ...] What about the restaurant?
From the Rock of Age Home for Retired Hackers:
--eugene miya, NASA Ames Research Center, eugene@ames-nas.ARPA
------------------------------
Date: Fri, 27 Sep 85 12:01:18 EST
From: munnari!mulga.oz!bjpt@seismo.CSS.GOV (Benjamin Thompson)
To: risks@sri-csl.ARPA
Subject: Re: Technology and Morality
Organization: Computer Science, University of Melbourne
Nicholas Spies writes [in RISKS-1.13]:
> ... Hitler opened the Pandora's Box of applying
>high-tech to warfare and it worked (at least until a higher-tech response
>prevailed).
Technology has been successfully applied to warfare for millenia. Alexander
the Great didn't win through having a bigger army (he didn't); he had better
weapons (e.g. he found out that ballistae propel spears faster than people do).
(and he had better trained soldiers etc. - education and technology basically).
> After WWII a new era was born in which global political power no
>longer rested on moral authority but on a command of the new applied
>sciences and scientists.
Nothing could be further removed from morality than the way in which global
political power is grabbed and maintained. It has always been based upon
physical strength (which usually, but not always, corresponds to technological
strength). History is a never-ending sequence of examples.
------------------------------
Date: 26 Sep 1985 0920-PDT
From: Rob-Kling <Kling%UCI-20B@UCI-ICSA>
Subject: Social Impacts of Computing: Graduate Study at UC-Irvine
To: risks@SRI-CSL
CORPS:
Graduate Education in
Computing, Organizations, Policy, and Society
at the University of California, Irvine
This graduate concentration at the University of California,
Irvine provides an opportunity for scholars and students to
investigate the social dimensions of computerization in a setting
which supports reflective and sustained inquiry.
The primary educational opportunities are PhD concentrations in
the Department of Information and Computer Science (ICS) and MS and
PhD concentrations in the Graduate School of Management (GSM).
Students in each concentration can specialize in studying the social
dimensions of computing.
The faculty at Irvine have been active in this area, with many
interdisciplinary projects, since the early 1970's. The faculty and
students in the CORPS have approached them with methods drawn from the
social sciences.
The CORPS concentration focuses upon four related areas of inquiry:
1. Examining the social consequences of different kinds of computerization
on social life in organizations and in the larger society.
2. Examining the social dimensions of the work and organizational
worlds in which computer technologies are developed, marketed,
disseminated, deployed, and sustained.
3. Evaluating the effectiveness of strategies for managing the
deployment and use of computer-based technologies.
4. Evaluating and proposing public policies which facilitate the
development and use of computing in pro-social ways.
Studies of these questions have focussed on complex information
systems, computer-based modelling, decision-support systems, the
myriad forms of office automation, electronic funds transfer systems,
expert systems, instructional computing, personal computers, automated
command and control systems, and computing at home. The questions
vary from study to study. They have included questions about the
effectiveness of these technologies, effective ways to manage them,
the social choices that they open or close off, the kind of social and
cultural life that develops around them, their political consequences,
and their social carrying costs.
CORPS studies at Irvine have a distinctive orientation -
(i) in focussing on both public and private sectors,
(ii) in examining computerization in public life as well as within
organizations,
(iii) by examining advanced and common computer-based technologies "in
vivo" in ordinary settings, and
(iv) by employing analytical methods drawn from the social sciences.
Organizational Arrangements and Admissions for CORPS
The CORPS concentration is a special track within the normal graduate
degree programs of ICS and GSM. Admission requirements for this
concentration are the same as for students who apply for a PhD in ICS or an
MS or PhD in GSM. Students with varying backgrounds are encouraged to apply
for the PhD programs if they show strong research promise.
The seven primary faculty in the CORPS concentration hold appointments
in the Department of Information and Computer Science and the Graduate
School of Management. Additional faculty in the School of Social Sciences,
and the program on Social Ecology, have collaborated in research or have
taught key courses for CORPS students. Our research is administered through
an interdisciplinary research institute at UCI which is part of the Graduate
Division, the Public Policy Research Organization.
Students who wish additional information about the CORPS concentration
should write to Professor Rob Kling (Kling@uci-icsa), Department of
Information and Computer Science, University of California, Irvine, Irvine,
Ca. 92717, 714-856-5955 or 856-7548, or Professor Kenneth Kraemer
(Kraemer@uci-icsa), Graduate School of Management, University of California,
Irvine, Irvine, Ca. 92717, 714-856-5246.
------------------------------
Date: Wed, 25 Sep 85 01:17:53 pdt
From: mips!mash@glacier (John Mashey)
To: risk@sri-csl.ARPA
Subject: Friendly enemy test teams
John McCarthy <JMC@SU-AI.ARPA> writes in RISKS-1.10:
> 2. My opinion is that if the physics of the problem permits a good
> anti-missile defense the programs can be written and verified. However, it
> will be quite difficult and will require dedicated work. It won't be done
> by people who are against the whole project. Computer checked proofs of
> program correctness will probably play some role. So will anticipating what
> kind of bugs would be most serious and putting the biggest effort into
> avoiding them. Having many people go over and discuss all the critical
> parts of the program will also be important.
Perhaps the best way to make it work WOULD be to have a test team of
people (who might be skeptics, at least) trying to break it. Most large
complex projects that actually worked, at least that I've seen, have
succeeded at least partly because they had a large test team who didn't
believe anything worked until it could get past the worst of their tests.
I don't know what the ratio is elsewhere, but many complex ATT/BTL projects
allocated 30-50% of the staff to building test frameworks designed to stress
the system under test. Consider the recent history of evaluation of
new military systems (like the Sergeant York). It's very hard for the
builders of something to evaluate it well; you need a good enemy for that.
[Tiger teams have indeed had some success in finding the more obvious
program bugs, but in general many flaws may remain. This topic has been
raised superficially in past issues. Perhaps we are ready for some
detailed discussions on the strengths and limitations of testing. PGN]
------------------------------
Date: Thu, 26 Sep 85 22:29:41 EST
From: davy@purdue-ecn.ARPA (Dave Curry)
To: risks@sri-csl.arpa
Subject: More protocol goofs
[The original message contained 8576 characters, almost exclusively
headers. I have pruned it to give just the flavor. PGN]
I'm forwarding this as a wonderful example of protocols getting
completely hosed... this mail of mine bounced for some unexplained
reason. I resent the message the same day this came back, and it
went through just fine.
Looking at the headers should make the problem more than obvious...
--Dave Curry
Return-Path: <decvax!mcnc!unc!unc!unc!unc!unc!unc!unc!unc!mailer-daemon>
Received: from ee.ECN by ec.ECN; Thu, 6 Sep 84 19:48:01 est (4.12/5.20)
From: decvax!mcnc!unc!unc!unc!unc!unc!unc!unc!unc!mailer-daemon
Received: by ee.ECN; Thu, 6 Sep 84 19:47:35 est (4.12/5.20)
Return-Path: <decvax!mcnc!unc!unc!unc!unc!unc!unc!unc!unc!mailer-daemon>
Received: by decvax.UUCP (4.12/1.0)
id AA24764; Thu, 6 Sep 84 02:25:55 edt
Received: by mcnc (4.12/4.7) id AA00613; Wed, 5 Sep 84 18:51:54 edt
Original-From: <unc!unc!unc!unc!unc!unc!unc!unc!mailer-daemon@mcnc>
[... and so on iteratively, ad nauseum, down to... ]
Received: by unc (4.12/4.7) id AA06045; Wed, 5 Sep 84 09:07:16 edt
Original-From: <mailer-daemon@mcnc>
Received: by mcnc (4.12/4.7) id AB15479; Wed, 5 Sep 84 08:01:18 edt
Date: Sat, 1 Sep 84 10:03:51 est
Original-From: Mail Delivery Subsystem <MAILER-DAEMON@mcnc>
Subject: Returned mail: Unable to deliver mail
To: mcnc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!pur-ee!davy@unc
----- Transcript of session follows -----
554 sendall: too many hops (30 max)
----- Unsent message follows -----
Received: by mcnc (4.12/4.7) id AA15479; Wed, 5 Sep 84 08:01:18 edt
From: <mcnc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!pur-ee!davy@unc>
Received: by unc (4.12/4.7) id AA03055; Wed, 5 Sep 84 07:04:54 edt
Original-From: <mcnc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!unc!mcnc!pur-ee!davy@mcnc>
[...]
[I am reminded of the tale of the unattended British power station
equipped with an automatic calling unit to report troubles. When it
finally had to dial the emergency reporting number, it received a
recorded message that the number it had dialed was not valid. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂27-Sep-85 0930 JOHN@SU-CSLI.ARPA Philosophy 287A
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 27 Sep 85 09:30:21 PDT
Date: Fri 27 Sep 85 09:26:02-PDT
From: John Perry <JOHN@SU-CSLI.ARPA>
Subject: Philosophy 287A
To: folks@SU-CSLI.ARPA
cc: philosophy@SU-CSLI.ARPA
Philosophy 287A: Topics in Language and Information.
Fall Quarter, Mondays at 1:15, Ventura Hall Seminar Room.
The topic will be folk psychology and cognitive science. We will
discuss Stephen Stitch's recent book FROM FOLK PSYCHOLOGY TO
COGNITIVE SCIENCE: THE CASE AGAINST BELIEF, in which he argues
that our ordinary psychological concepts, such as belief, are
pretty confused and have not place in cognitive science. I
expect to develop a line of argument opposed to Stitch, based on
the point of view developed in Part D of Barwise&Perry SITUATIONS
AND ATTITUDES, maintaining that folk psychology isn't such a
mess, and might have some role in cognitive science. In addition
to Stitch's book, we will examine a couple of key articles by
Fodor and also Dan Dennett's attack on belief, "Beyond Belief".
Background reading in recent philosophy of mind and philosophy of
psychology will also be assigned.
≠
-------
∂27-Sep-85 0934 BETSY@SU-CSLI.ARPA 1986 Site Visit
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 27 Sep 85 09:34:45 PDT
Date: Fri 27 Sep 85 09:30:25-PDT
From: Betsy Macken <BETSY@SU-CSLI.ARPA>
Subject: 1986 Site Visit
To: folks@SU-CSLI.ARPA
CSLI's 1986 SDF Site Visit will be on Tuesday, June 24. SDF is
going to invite some of the same people who came last year, but
may include some others as well.
We don't know any other details, but the visit will play an important
role in determining whether or not SDF gives additional money to CSLI.
We'd like to have our researchers well represented so that our
presentation can show off all aspects of our research, so we hope that
with this early notice many of you can arrange to be here on that day.
We know we can't expect everyone to be here, but we hope you will take
the site visit into account in making your long-term plans.
Thanks.
Betsy
-------
∂27-Sep-85 1554 BSCOTT@SU-SCORE.ARPA Lost Articles, Yesterday's Reception
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 27 Sep 85 15:54:48 PDT
Date: Fri 27 Sep 85 15:49:06-PDT
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: Lost Articles, Yesterday's Reception
To: CSD@SU-SCORE.ARPA
cc: BScott@SU-SCORE.ARPA
Message-ID: <12146691477.25.BSCOTT@SU-SCORE.ARPA>
The caterer for yesterday's reception has reported that one large black
lacquer tray and three serving spoons are missing from the serving
paraphernalia they picked up from the MJH kitchen today. If anyone has
seen any of the missing items, I will appreciate hearing from her or him.
If they can't be located, the Department will have to pay for the loss.
Thanks for your help.
Betty
-------
∂27-Sep-85 1606 LIBRARY@SU-SCORE.ARPA Math/CS Library Fall Hours
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 27 Sep 85 16:06:21 PDT
Date: Fri 27 Sep 85 15:53:06-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library Fall Hours
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12146692204.49.LIBRARY@SU-SCORE.ARPA>
The Math/CS Library has started its fall hours. Monday through Thursday
8am to 10pm. Friday 8am to 6pm. Saturday 10am to 5pm. Sunday 1pm to
10pm.
H.Llull
-------
∂27-Sep-85 1615 LIBRARY@SU-SCORE.ARPA Socrates: New Version To Be Activated On Sunday, September 29th
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 27 Sep 85 16:15:36 PDT
Date: Fri 27 Sep 85 16:06:21-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: New Version To Be Activated On Sunday, September 29th
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12146694618.49.LIBRARY@SU-SCORE.ARPA>
The new version of Socrates should be available this Sunday. The new
Socrates will have a Guided mode and Command mode that will work a little
differently then the old Lookup and Command modes. There will be less of
a barrier between the two modes. I will be sending out more messages next
week concerning this new feature and other new features.
For those faculty and students in Computer Science, you will be most interested
in the fact that the new Technical Reports File includes all the reports
collected in the Math/CS Library. The Technical Reports File is a separate
file and must be selected before one can search it either in the Guided mode
or Command mode.
If you have any questions or concerns about the new Socrates, you can use
the SUGGEST command to express your opinions. I would also be interested
in hearing from you if you are experiencing any diffculties in searching
the new version of Socrates.
For those of you who do not have an individual Socrates account, you may
come to the Math/CS Library to fill out a form and pick up your account
number.
I will announce on the bulletin board when I have the guide sheets to the
new version of Socrates.
Harry Llull
-------
∂29-Sep-85 1439 @SU-SCORE.ARPA:lantz@su-gregorio.arpa Re: speaking at orientation day
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Sep 85 14:39:44 PDT
Received: from su-gregorio.arpa by SU-SCORE.ARPA with TCP; Sun 29 Sep 85 14:36:30-PDT
Received: by su-gregorio.arpa with Sendmail; Sun, 29 Sep 85 14:36:40 pdt
Date: 29 Sep 1985 1436-PDT (Sunday)
From: Keith Lantz <lantz@su-gregorio.arpa>
To: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Cc: MikeDixon.pa@XEROX.ARPA, faculty@SU-SCORE.ARPA, WIEDERHOLD@SUMEX-AIM.ARPA,
REGES@SU-SCORE.ARPA
Subject: Re: speaking at orientation day
In-Reply-To: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA> /
Tue 17 Sep 85 09:12:14-PDT.
<12143997789.10.TAJNAI@SU-SCORE.ARPA>
Although I'm at least two weeks removed from the bulk of this
conversation (having been away during that period), I would strongly
favor moving the CS Colloquium back to the vicinity of Margaret Jacks
(or somewhere on a somewhat direct line between there and the CIS bldg.)
whether or not that meant keeping it on TV. I am convinced that in the
first two years I was at Stanford, when it was in Jordan, many more
faculty and staff attended than do now. As for the effect of TV
itself, my own experience is not positive -- whether for the colloquia
or for courses -- but I appreciate the financial benefits.
Keith
∂30-Sep-85 0157 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #41
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 01:57:41 PDT
Date: Sunday, September 29, 1985 4:59AM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #41
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Monday, 30 Sep 1985 Volume 3 : Issue 41
Today's Topics:
Query - Prolog for Apple IIe,
Challenge - Ken Law's,
LP Philosophy - Hewitt's Challenge,
Implementation - DCG's & Destructive Assignment
----------------------------------------------------------------------
Date: Wed, 25-Sep-85 14:38:38 PDT
From: (Craig D. Singer) mcnc!duke!cds@UCB-Vax.ARPA
Subject: Prolog for Apple IIe
Does anybody know where we might purchase a non-copy-protected
version of Prolog for the Apple IIe? This software is strictly
for educational use, and we have about three or four Apples we'd
like to be able to run it on simultaneously; hence, the need for
a copyable program. One or two of the Apples are enhanced and
one or two of them are not, but that is not a major concern.
We simply need software which our AI grads can use without having
to handle the disk with extreme delicacy. Alternatively, we would
consider purchasing (or, ahem, graciously accepting) the printed
or downloaded source. If you can help, please send mail or post
something here...we read this newsgroup daily.
Thank you now for good deeds later!
-- Craig Singer
------------------------------
Date: Fri 27 Sep 85 16:14:09-PDT
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Connected-Component Extraction
My thanks [to Allen VanGelder] for considering the connected
-component extraction problem. After sending it off to Phil-Sci,
I realized thatI was really asking for an automated programming
solution rather than a logic programming solution -- and I don't
expect anyone to come up with one. The question remains, though,
whether expressing a problem in a logic formalism will help the
programmer develop an algorithmic solution. I'm sure the answer
depends on the problem, the logic formalism, and the programmer.
The problem statement was a little imprecise. I did indeed have a
2-dimensional array in mind, although I believe that any algorithm
would be essentially the same for higher dimensionalities. I also
had just rectilinear neighbors in mind, although permitting diagonal
neighbors makes just as good a problem. (There is a quirk in the
computational geometry, though; allowing diagonal connectedness
permits connected components that intersect each other. This
plays havoc with containment relationships. Some pattern
recognition systems use diagonal connectedness for foreground
objects and rectilinear connectedness for the background, but
that won't work for other than binary arrays.)
Shortly after submitting the problem, I ran across an algorithm
for solving it (in the binary case) using a pyramid of
interconnected processors. The algorithm was so clever that I
can't remember it now. Maybe we do need automated programming
systems to derive optimal algorithms for any hardware or
circumstance, but some of the procedural solutions people have
invented (often for ill-defined problems) are awe-inspiring.
-- Ken Laws
------------------------------
Date: Thu, 26 Sep 85 10:29 EDT
From: Tim Finin <Tim%upenn.csnet@CSNET-RELAY.ARPA>
Subject: Lisp and Prolog
PROLOG/LISP = LISP/C
I'd like to amplify a point of view Clocksin put forth in V3
#39 in the great LISP vs. PROLOG debate. Prolog (and Logic
Programming in general) and Lisp are both tools which are suited
for different tasks. Luckily, none of us is being forced to use
one to the exclusion of the other.
I've had to give more than my share of introductory AI talks over
the years. When the discussion gets around to Lisp I usually point
out that Lisp is especially attractive for experimental programming
situations, i.e. where you know what you want to accomplish but do
not yet have all of the details as to algorithms, data structures,
etc. worked out. Once you've worked out the last detail, you can
re-implement your system in C, if you like, and gain the benefits
of a faster and smaller system.
Along these lines, I think that the slogan "Prolog is to Lisp as
Lisp is to C" is not too inaccurate. I think that Prolog is even
better suited to initial, experimental and exploratory attempts to
attack a problem computationally. I find that it is a very
convienent paradigm in which to get started. Once I have a better
idea of how to reprent a problem and how to manipulate the
representation, I can re-implement it in Lisp and gain a faster
more steamlined system.
-- Tim
------------------------------
Date: Thu 26 Sep 85 15:45:15-PDT
From: Fernando Pereira <PEREIRA%sri-candide@sri-marvin>
Subject: DCGs and parsing strategy
First, let's get rid of one misconception about DCGs. DCGs
are not ``top-down'' any more than, say, context-free grammars.
I have top-down, bottom-up, left-corner, Earley, and various
chart-parsers for DCGs, all implemented in Prolog.
Now for the minimal bottom-up (actually, left-corner) DCG parser.
The parser is itself a DCG (a DCG metainterpreter, if you wish)
that takes rules given by the binary predicate ==>. To parse a
string S as having category C, call
?- down(C,S,[]).
Here is the code:
down(Phrase) --> leaf(SubPhrase), lc(SubPhrase,Phrase).
leaf([Word]) --> [Word].
leaf(Phrase) --> { Phrase ==> [] }.
terminals([]) --> [].
terminals([Word|Words]) --> [Word], terminals(Words).
lc(Phrase,Phrase) --> [].
lc(SubPhrase,SuperPhrase) -->
{ Phrase ==> [SubPhrase|Rest] },
right(Rest),
lc(Phrase,SuperPhrase).
right([]) --> [].
right([Phrase|Phrases]) -->
down(Phrase),
right(Phrases).
Note that the sequence of symbols to the right of the arrow is
written as a list (rather than as a `,'-separated sequence) in
the object grammar. A few modifications are needed to handle
{...} conditions and terminal sequences [...]. It is possible
to make the code much more efficient by partial evaluation
with the object grammar and other compile-time optimizations.
-- Fernando Pereira
------------------------------
Date: Thu 26 Sep 85 15:20:03-PDT
From: Fernando Pereira <PEREIRA%sri-candide@sri-marvin>
Subject: Destructive Assignment
Rick McGueer seems to be confused about the differences between
structure sharing and non-structure sharing methods of term
representation in Prolog. In both methods, if we want to ``change''
an argument of a functor, say `a' by `b' in f(X,a,Y), what Prolog
copies is a chunk of c*n+k cells where c and k are implementation
-defined constants and n is the arity of the functor. When replacing
a subterm at depth m of a term t, the number of cells copied is
sum(i=0..m-1,c*n←i+k) where n←i is the arity of the functor at depth
i. If the data structures are kept well balanced, it follows that
the cost of updating a term of height m is O(log m). Of course,
this is just a particular case of the fact that a random-access
memory of size s can be simulated by assignment-free data structures
at an overhead of O(log s). In applications I have developed, this
overhead is a small cost to pay for ease of programming and the
space recovery efficiencies inherent in the stack allocation used
by any reasonable Prolog.
-- Fernando Pereira
PS: Cf. discussions on arrays in Prolog in earlier Digests, the
paper ``Incorporating Mutable Arrays into Logic Programming''
by Lars-Henrik Eriksson and Manny Rayner, and David H. D.
Warren's logarithmic array code in the collection at
SCORE:<PROLOG>
------------------------------
Date: 26 Sep 85 23:58:16 PDT
From: Deutsch.PA@Xerox.ARPA
Subject: Destructive Assignment
Again, I would like to suggest a different view of assignment
than Rick McGeer's last comment. If A is embedded in B, C, and
D, the routines manipulating B, C, and D don't need to know
anything at all about the structure of A: all they need to know
is that they have to embed the modified A in their own structure
in the appropriate place, namely the place they got it from in
the first place to be able to tell it to modify itself. Whether
a language has abstraction is independent of whether it has
assignment. I consider Prolog's lack of abstraction and
modularity a much more serious problem for its use in systems
than its lack of destructive assignment.
------------------------------
Date: Fri, 27 Sep 85 10:32:44 PDT
From: (Rick McGeer) Mcgeer%ucbkim@Berkeley.EDU
Subject: Destructive Assignment, again...
Your argument is well-founded, but the principal argument for
destructive assignment is modularity, not efficiency. Consider
two data structures, A and B, that share some common substructure
C. Now, if C is modified, a new copy of C, C' is created. In
most applications, one wants the data structures A and B to
contain the new substructure C'. Am I wrong in believing that A'
and B' must be created in the absence of destructive assignment,
since both A and B are now outdated? And if I'm correct, isn't
it also the case that the parents of A and B must also be modified,
and so on recursively.
If program data structures were treelike rather than networklike
(in short, if no two data structures shared common substructure),
then copying is reasonable since one assumes that the only method
of accessing substructure is through the root of the tree, and
superstructures can be appropriately modified through the accessing
traversal. If data structures are networklike, the problem is harder,
since the access to the substructure can come through one of a number
of parents, which means that the code which modifies the substructure
must be able to access all the parents of the substructure, and so on
through the data structure.
My own programs tend to shared structure a fair amount, which is why
I'm banging away at this problem. It turns out that there's a way
to hack the moral equivalent of destructive assignment into Prolog
(using lists with unbound cdrs), but this requires time O(n) for a
set or access, where n is the number of times that this variable has
been set...
Anyway, if I'm confused about this, I'd appreciate any pointers that
you have to programming techniques to avoid the problem of shared
structure.
-- Rick.
------------------------------
Date: Fri, 27 Sep 85 15:39:51 PDT
From: (Rick McGeer) Mcgeer%ucbkim@Berkeley.EDU
Subject: Destructive Assignment, again
Yes, I thought of that, too. I rejected it because it seemed
to defeat one of the central purposes of symbolic languages,
namely getting rid of explicit pointers. Further, after examing
the Warren PLM I couldn't think of a good way to do this invisibly
without major surgery to the PLM. Destructive assignment, however,
required only oen new instruction (rplacarg), and modifying the
trail to contain 2 longwords per entry rather than one.
-- Rick
------------------------------
Date: Fri, 27 Sep 85 13:44:33 PDT
From: Deutsch.pa@Xerox.ARPA
Subject: Destructive Assignment, again...
Thanks for your thoughtful reply. As you point out, the natural
underlying structure of the data may be an unrestricted graph,
for which I don't know how to construct a purely functional
representation that models edges as pointers. However, it's
easy to construct a functional representation that doesn't model
edges as pointers: divide the structure up into a set of nodes
represented by unique ids, and a separate dictionary that maps a
node id to the contents of the node it represents. This
representation caters nicely to the problem of updating an
interior node and having the update visible from anywhere that
references it. In effect, a level of indirection has been
introduced. While the dictionary itself must be global to the
structure involved, it doesn't have to know anything about the
semantics of the individual nodes or edges, so logical modularity
is still preserved. And the indirection can be covered with
syntactic sugar to eliminatemost of the burden on the programmer:
all that is necessary is that node references be represented as
pairs <containing structure, node identifier>, and that all node
updates return a new containing structure with appropriate
modifications. All that remains is to make sure the garbage
collector knows it can remove any dictionary entries where the
id isn't accessible -- in effect, knows that the dictionaries are
being used to simulate a memory system.
In circumstances where the natural structure of the data is not an
unrestricted graph, pointers can be modelled as pointers, and
reconceptualizing the algorithms to use paths or indices rather
than direct references may yield more transparent programs. (It's
been my experience that a lot of the bugs that arise in systems are
the result of implicit transmission of side-effects through sharing
of references to mutable structures.)
There have been a number of papers in the Lisp / Functional
Programming symposia on the subject of effective programming
without side effects. That would be the first place I would
look for references.
------------------------------
Date: 27 Sep 85 18:05:34 PDT
From: Deutsch.pa@Xerox.ARPA
Subject: Destructive Assignment, again...
Wait a minute. Surely destructive assignment implies the
existence of "reference" as a concept that is visible to
the programmer? And how is this different from "explicit
pointers"? In a functional language, the concept of
"reference" disappears -- you can't tell the difference
between eq and equal (and in fact the implementor is free
to adopt strategies that may copy or share, ad lib.) The
dodge I suggested simply makes references explicit in those
(and only those) places where their semantics are needed.
In Prolog, logical variables create a kind of sharing that
is pretty much just like a reference. In this respect Prolog
feels quite different to me than a functional language. On
the other hand, there may be a way to think of Prolog clauses
as functions from environments to environments that is more
like what I suggested. Also, in principle the Prolog
implementor is free to use a mix of copying and sharing
strategies (e.g. Prolog on a multi-processor will probably have
to do some copying), as long as the equality constraints between
occurrences of a given variable are extended to include any
copies.
------------------------------
End of PROLOG Digest
********************
∂30-Sep-85 0221 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #19
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 02:21:09 PDT
Date: 30 Sep 85 0144-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #19
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Monday, 30 Sep 1985 Volume 1 : Issue 19
Today's Topics:
Recent posting on Japan trip by Charles Watson
Parallel Lisp environments
Simulators for hypercube architectures
Response to the First PARSYM Survey
Electronic clearinghouse for technical reports
----------------------------------------------------------------------
Date: Mon, 23 Sep 85 10:34:58 pdt
From: eugene@AMES-NAS.ARPA (Eugene Miya)
Subject: Recent posting by Charles Watson
As a quick addition to the note by Charles Watson on his
recent visit to Japan:
We are trying to use on of the Ames gateways to UUCP and the ARPAnet
to set up an informal groups of people to monitor foreign language
technical information. Our principal interest right now is Japanese
because as Charles found out, a lot is being done there.
We don't want to form a new bulletin board [there are too many now],
but we want to identify individuals capable of translating foreign
technical material, identify significant non-translated journals,
and then ask people to post significant papers as they emerge to speed
translation or interest.
The Usenet has a newsgroup, net.mag, where people post the TOCs of
significant new issues. What I am proposing is posting such TOCs
of new non-English material to existing bulletin boards. Where
interest exists, interested parties can get together and pay for
the cost of translation, thus identifying significant papers quickly.
If you are interested and can help translate some non-English
foreign material, please contact me. We have interest from people
all over Europe, and a couple of people in Japan.
--eugene miya
From the Rock of Ages Home of Retired Hackers
eugene@ames-nas
------------------------------
Date: Tue, 27 Aug 85 15:37:18 EDT
From: Deepak Kumar <kumard%buffalo.csnet@csnet-relay.arpa>
Subject: Parallel LISP Environments
[Forwarded from AIList by Laws@SRI-AI.ARPA]
We are planning to implement a parallel-environment
simulator in LISP for trying out various control
metaphors that require parallelism.
Anyone already having any implementations or
experiences in using such environments?
We would appreciate any kind of responses that could
help in highlighting various aspects of design as well
as implementation.
Thanx.
Deepak.
UUCP : {cmcl2,hao,harpo}!seismo!rochester!rocksvax!sunybcs!kumard
...{allegra,decvax,watmath}!sunybcs!kumard
CSNET : kumard@buffalo
ARPA : kumard%buffalo@csnet-relay
BITNET : kumard@sunybcs
------------------------------
Date: 30 Aug 85 13:54:23 EDT (Fri)
From: duke@mitre.ARPA
Subject: Simulators for hypercube architectures
[Forwarded from AIList by Laws@SRI-AI.ARPA]
Lisa Sokol (sokol@mitre) and I are investigating the use of parallel
architectures for object-oriented simulations. We have a large simulation
called the BEM (Battlefield Environment Model) which is written in the
simulation language ROSS, which runs on top of Franz LISP on a VAX. We
would like to have a hypercube simulator which would help us investigate
strategies for distributing objects in a hypercube. Our main problem seems
to be the integration of LISP code with the simulators. Translating the
Lisp into C would be messy at best, even with a translator program. Another
possibility would be to have Franz LISP running in another process on the
VAX and communicating with the simulator process. That sounds pretty messy
also, particularly for analyzing the timing since the Lisp is running
outside of the simulator process. For our purposes, it may be better to
write a Lisp simulator of a hypercube architecture. Do you know of anyone
who already has such a simulator? We expect that Lisp will be available on
some hypercube in the next year, and our simulator studies should allow us
to determine how to distribute the objects by that time.
Duke Briscoe
duke@mitre
------------------------------
Date: Thursday, 26 September 1985 16:24-PDT
From: zorn%ucbrenoir at Berkeley.EDU (Ben Zorn)
Re: Response to the PARSYM survey... (a little late, I'm afraid)
[Thank you -- it's never too late. For newcomers, the First PARSYM
Survey was devoted to goals for research in parallel computing. The
results of the survey were distributed as V1 #11 of the PARSYM digest,
which is available from PARSYM-Request@SUMEX-AIM.ARPA. -- BD]
The SPUR Project at Berkeley is interested in building a workstation
with 10-12 VLSI RISC-style processors specifically designed to run Lisp.
One phase of the project is to implement Common Lisp for SPUR and provide
primitives for multiprocessing. Here is our response to the survey.
Ben Zorn
Jim Larus
George Taylor
Prof. Paul Hilfinger
--------
1. What, if any, is your target application for parallel computing?
(Theoreticians aren't required to reply to this question.)
[Symbolic computation including expert systems, rule-based systems,
and algebraic manipulation systems. Other applications that might
benefit from LISP and multiprocessors.]
2. Is performance improvement your main goal in exploring parallel
computing?
[Yes. We are hoping to develop a programming style and a
sophisticated compiler and runtime system that will permit programmers
to utilize the multiple processors to speed up their applications.]
3. (a) If so, what degree of performance improvement does your target
application require (in, say, orders of magnitude)? What
degree of performance improvement does your current approach
promise?
[Given that the SPUR workstation will have at most 10-12 processors,
we expect a performance improvement of at most an order of magnitude.
We would be happy with a 4 or 5 times speed-up for most applications.]
(b) If not, what else do you expect to achieve through the use of
parallelism?
[Higher performance without increased chip complexity.]
------------------------------
Date: Fri, 27 Sep 85 13:38:21 cdt
From: Laurence Leff <leff%smu.csnet@CSNET-RELAY.ARPA>
Subject: Electronic clearinghouse for technical reports
I have volunteered to organize an electronic mechanism for the
distribution of technical report lists from Universities and R&D labs.
Some (and hopefully all) of the people producing technical reports
would send a copy of the list to me. I would then send these to a
moderated group on USENET as well as a mailing list for those sites on
the INTERNET who do not get news (ARPANET, CSNET, etc.).
I need two things from you:
1) if your organization prepares technical reports and sends them
out to interested parties (perhaps for a fee), please arrange
to have electronically readable copy of your lists sent
to trlist%smu@csnet-relay.
2) if people at your organization would like to receive lists
of tech reports produced by universities and R&D labs, please
provide me an electronic address to send them to (if you are not
on USENET). Send such administrative mail to trlist-request%smu@
csnet-relay.
Some frequently asked questions:
1. What are the advantages of sending my lists to you?
a. Most of the people to whom you are sending printed lists will be
receiving this list, either through the INTERNET as a mailing list or
as a moderated news group on the USENET distributed bulletin board
system. Thus you can save the postage and printing costs in mailing
these lists. I would be happy to provide you with a list of
institutions receiving this list as a mailing list as well as those
institutions on USENET who would be receiving it that way. You can
use this to prune the mailing list you use to send out printed copies
of your technical report lists.
b. Many people at the Universities are not aware of technical
report lists. I have been sending out lists of AI tech reports
to the AIList, an electronic newsletter on AI, for some time.
Every time I do so, my electronic mailbox fills up with requests on
how to obtain the tech reports. Many of these requests come from
the most prestigious AI organizations in the country.
c. Many companies, particularly those on the USENET, would not
otherwise be aware of your research. There are hundreds of small
companies on USENET who have no other access to the wealth of
information represented by University and other tech reports.
2. What is a technical report?
Most universities and big company R&D labs publish reports about their
research. Some are highly research oriented (like new results in
automata theory). Others are manuals for their public domain software
or tutorials. For example NASA/Ames published a tutorial on SETUID
programs under UNIX. These lists are currently sent out by mail to
other schools and R&D labs.
Some of the technical reports will later get turned into journal
articles while other items will never be more formally published.
Thus looking at these lists would give you information on new research
results before they would appear in journals or would let you know of
material you would not otherwise be aware of.
3. What format should the tech report lists be in?
Please see to it that there is some info indicating how people can
order the tech reports (whether sending you a check to cover costs,
requests via electronic mail or the reports can be electronically
available for Arpanet FTP transfer).
If you are already producing the list in some format, feel free to use
that format. If you are preparing the list just for this purpose, I
would prefer that you use the input format for bib/refer, a common
bibliography tool. This way people can dump the lists into a file on
their machine and be able to do keyword searches. Also bib/refer will
automatically include and format references in documents to be
formatted or typeset. However, I would prefer the material in some
weird format than not to have it at all!
For those not familiar with bib/refer, here is a brief tutorial. Each
report or other item should be a sequence of records which are not
separated by blank lines. Each report should be separated by the
others by one or more blank lines. Each report entry consists of a
label consisting of a % followed by a capital letter and then a space.
Then include the information. If the information for a field (such as
an abstract) requires more than one line, just continue the field on a
new line with no initial space.
The labels needed for tech reports are:
%A Author's name (this field should be repeated for each author).
%T Title of report
%R report number
%I issuer, this will be the name of your institution. This may
be ommited if implied by the report number
%C City where published (not essential)
%D Date of publication
%X Abstract
Here is an example of some tech report listings in the appropriate
format:
%A D. Rozenshtein
%A J. Chomicki
%T Unifying the Use and Evolution of Database Systems: A Case Study in
PROLOG
%R LCSR-TR-68
%I Laboratory for Computer Science Research, Rutgers University
%K frame control
%A C. V. Srinivasan
%T CK-LOG, A Calculus for Knowledge Processing in Logic
%R DCS-TR-153
%I Laboratory for Computer Research, Rutgers University
%K MDS
4. I already have exchange agreements with other Universities.
How does this affect them?
The only change would be how the information on what technical reports
you have for them to request gets transferred. Instead of them
receiving a piece of paper by U. S. Mail, they would look at the
appropriate notes group (if this is a USENET site) or at the item
received in the mail, request the reports they want and send the
request to you. You would probably request that the free technical
report order came from a specific person or account in case some
student seeing the list decided to order the tech reports. You should
do that with the printed lists anyway since at some schools, technical
report lists are frequently left around for graduate students and
faculty to look at and check the ones they want. Any person could
send in the form themselves if they chose.
5. I need to charge for my tech reports to cover costs.
Fine. Just include the prices for your reports next to each report (you can
use the %X field for that too). At the beginning of the list you send me,
state where checks should be sent and to whom they should be made payable.
6. What about non-CS reports?
I am happy to handle reports for other departments. If the volume of
non-CS reports becomes significant, I will split the list into tr-cs,
tr-math, tr-ee etc. I would suspect that the majority of the people
receiving this list would be CS researchers since CS departments are
quick to join networks, etc. However, some CS researchers (myself
included) are working in applications of computers and would like to
receive information in those areas as well.
7. I am already on USENET. What should I do?
I anticipate a USENET moderated group in a time frame of one to two
weeks which will contain the same information as the technical report
lists. If you indicate that you will get the information via USENET,
I will remove your name when the list is established. If you want to
wait a week or two to see if the list comes up, that is OK too. I can
send back copies of the TR Lists that get sent out in the first few
batches of the mailing. I will also send out on the USENET group,
everything that got sent out in the mailing list so you won't miss
anything either way.
8. I am on Arpanet, BITNET, etc.
I can get to Arpanet sites through csnet-relay so there is no problem
there. Otherwise, send me your address as best you know it. I will
get through to you if at all possible.
------------------------------
End of PARSYM Digest
********************
∂30-Sep-85 0829 PATASHNIK@SU-SUSHI.ARPA Abstracts
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 08:29:37 PDT
Date: Mon 30 Sep 85 08:26:26-PDT
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: Abstracts
To: aflb.all@SU-SUSHI.ARPA
Here are abstracts for the first two AFLB talks this quarter.
****************************************************
3-Oct-85 - Umesh Vazirani (MSRI)
Sampling a Population, with a Slightly-random Source
Consider the following question: Given a box containing red and blue
tickets, we wish to estimate the percentage of red ones. A result
from elementary probability theory is that a constant number of
samples suffice, independent of the size of the population. This
simple but very surprising fact has obvious applications in gallup
polls and consumer surveys. In computation, this fact forms the basis
of Monte-Carlo or Randomizing Algorithms.
The problem we consider is: How do we pick a random sample? The
difficulty is that the available sources of randomness such as Zener
diodes, and geiger counters are imperfect. They do not output
unbiased, independent coin flips. An imperfect source of randomness
can be modelled as an adversary source, the slightly-random source: An
adversary with infinite computing power, and complete knowledge of our
algorithm generates the successive bits of output of the source. The
only constraint on the adversary is that each successive bit must be 1
with probability at least delta, and 0 with probability at least
delta, for any fixed constant 0 < delta < 1/2.
We prove that O(n logn) samples suffice to sample a population of size
2**n, using a slightly-random source to generate the sample points.
As a consequence of this sampling theorem we strengthen the SRp = Rp
result in two ways:
Theorem 1: SBPP = BPP.
Theorem 2: RTIME(T) is contained in SRTIME(O(T logT)).
Theorem 2 says that any probabilistic algorithm that runs in time T
can be converted into an algorithm that runs in time O(T logT), and is
guaranteed to work even if its source of random bits is a
slightly-random source instead of a fair coin.
***** Time and place: October 3, 12:30 pm in MJ352 (Bldg. 460) ******
10-Oct-85 - Eli Shamir (Hebrew University)
New results about graph coloring
The chromatic number of a random graph with expected degree d(n) is
sharply concentrated around b*d(n)/logd(n). There are provably good
heuristics to unravel the coloring of a dense graph with an unusually
small number of color classes.
***** Time and place: October 10, 12:30 pm in MJ352 (Bldg. 460) ******
-------
∂30-Sep-85 0935 RICHARDSON@SU-SCORE.ARPA Tuesday Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 09:35:45 PDT
Date: Mon 30 Sep 85 09:33:53-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Tuesday Lunch Series
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA, bureaucrats@SU-SCORE.ARPA
Message-ID: <12147409604.12.RICHARDSON@SU-SCORE.ARPA>
Tomorrow, Oct. 1, at 12:15 in MJH Room 146 the Tuesday Lunch Series
continues with Dwain Fullerton on "Fund Raising".
Anne
-------
∂30-Sep-85 1359 DAVIES@SUMEX-AIM.ARPA No meeting this week
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 13:58:54 PDT
Date: Mon, 30 Sep 1985 13:59 PDT
Message-ID: <DAVIES.12147457986.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: No meeting this week
cc: Davies@SUMEX-AIM.ARPA
There will be no meeting of the Advanced Architectures Project this
week. Both Ed and Penny are out of town, and no one expressed any
great interest in having a meeting.
There will be a meeting next week on Wednesday, Oct. 9 at 9:30 am.
The topic will be announced by this coming Friday.
-- Byron
∂30-Sep-85 1417 NILSSON@SU-SCORE.ARPA Course Schedule Policy
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 14:16:52 PDT
Date: Mon 30 Sep 85 14:02:01-PDT
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Course Schedule Policy
To: ac@SU-SCORE.ARPA
cc: berg@SU-SCORE.ARPA
Message-ID: <12147458414.37.NILSSON@SU-SCORE.ARPA>
I have had some complaints that there is a general lack of consistency
between the CS course listings in "Courses and Degrees" and the final
quarterly time schedule. There are also apparently several unapproved
changes in course times that occur near the beginning of a
quarter--after the time schedule comes out. These changes are all very
difficult for our students who rely heavily on the information in
"Courses and Degrees" to plan their schedules.
We should remind ourselves of the department policy on course
scheduling--established at the Faculty Meeting on 10 January 1984:
"Once a year, the Curriculum Committee is charged with updating Courses
and Degrees. Subsequently, each professor will receive a notice with
information about courses, quarters to be taught, and time slots.
Prior to final galley reading of Courses and Degrees, requests for changes,
additions, and deletions can be submitted to the Publications Coordinator
who will in turn refer them to the Curriculum Committee and to the Chairperson
for final approval. Changes will be considered only if they do not cause
conflicts, and if appropriate classroom space is available. Once the final
galley reading in the Editorial Office has taken place, no course can be
changed from one quarter to another. Instructors must hold the first class
meeting at the prescribed time and place. Upon completion of Courses and
Degrees, there is a commitment to teach the courses as stated. No changes
will be accepted for quarterly time schedules, since these must reflect
information contained in Courses and Degrees."
I assume that the faculty had good reasons for adopting this policy and
that those reasons still obtain. Please let me know if there are
situations in which exceptions must occur. Thanks, -Nils
-------
∂30-Sep-85 1430 MAYR@SU-SCORE.ARPA topics for prob. theory course
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 14:30:15 PDT
Date: Mon 30 Sep 85 14:26:22-PDT
From: Ernst W. Mayr <MAYR@SU-SCORE.ARPA>
Subject: topics for prob. theory course
To: faculty@SU-SCORE.ARPA
Message-ID: <12147462849.29.MAYR@SU-SCORE.ARPA>
Brad Efron from the Statistics Dept. has offered to teach a course in
Probability Theory/Statistics (say at a level comparable to Stat116) which
could be particularly aimed at CS students, or topics we'd like our students
to know about. Right now, Stat116 is taught three times a year (fall, spring,
and summer), and this new course could replace one of these offerings.
I am trying to compile a list of topics in Probability Theory and Statistics
that are relevant to our CS students, and I am asking your help. Of course,
there are some basic things every such course must contain (random variables,
event spaces, conditional probabilities, the main distributions, basic facts
about tests, a.m.m.). What else would you like to see? Like:
- distributions of sums/max/functions of many r.v.'s
and estimates for those
- Chernoff bounds
- more extensive treatment of binary r.v.'s
- construction of r.v.'s with certain distribution from others (computational
methods)
- more treatment of dependent r.v.'s (whatever one can do here)
- ???
ernst
-------
∂30-Sep-85 1828 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 18:26:34 PDT
Received: from ames-vmsb.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Sep 85 18:15:15-PDT
Date: 30 Sep 85 17:51:00 PST
From: welch@ames-vmsb.ARPA
Subject: SIGBIG
To: super@su-score.arpa
Reply-To: welch@ames-vmsb.ARPA
ASSOCIATION FOR COMPUTING MACHINERY
San Francisco Golden Gate Chapter
"SIGBIG" Special Interest Committee
For Large High Speed Computers
Meetings on the first Wednesday of each month at 7:30 PM. Speakers
who can give insights to various aspects of SUPERCOMPUTING are
featured each month.
Next meeting:
Wednesday, October 2,1985, 7:30 PM
A SIGBIG general business meeting will be held at
ZeroOne Systems,Inc. SIGBIG goals will be discussed
and tasks for new volunteers will be discussed.
Please bring your Ideas.
Location: ZeroOne Systems, Inc. "01"
2431 Mission College Blvd.
Santa Clara, CA.
Directions: From Hwy 101, North onto Great America Parkway.
Right,East on Mission College Blvd. Left,North
at second light into parking.
---------------------------------------------------------------
Tape-recordings of most of the previous may be obtained
in exchange for a tape cassette or $5.00 by contacting:
Mary Fowler (415)261-4058 (rec)
Supercomputing #192, BOX 2787
Alameda, CA. 94501-0787
For information contact Mary Fowler, Chairperson (415) 839-6547
or Mike Austin, Publ. Chair (415) 423-8446
------
∂30-Sep-85 2209 ACUFF@SUMEX-AIM.ARPA Explorer meets TCP
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 22:09:03 PDT
Date: Mon 30 Sep 85 22:08:17-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Explorer meets TCP
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12147546937.74.ACUFF@SUMEX-AIM.ARPA>
Beta TCP is now running on the Explorer. Unfortunately, TCP comes
with an unstable system (an kludged together mid-release development
system), so be sure to read the notes tacked to the wall beside the
console, or look in <Acuff>TI-TCP.DOC before using the Explorer.
These notes cover how to use the new system, as well as caveats and
known bugs, though I doubt it is complete. Release 1.0 is still
available also.
-- Rich
-------
∂01-Oct-85 0855 RICHARDSON@SU-SCORE.ARPA Tuesday Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 08:55:45 PDT
Date: Tue 1 Oct 85 08:52:31-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Tuesday Lunch Series
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA, bureaucrats@SU-SCORE.ARPA
Message-ID: <12147664216.23.RICHARDSON@SU-SCORE.ARPA>
Don't forget lunch today at 12:15 in MJH 146!
Anne
-------
∂01-Oct-85 0903 JF@SU-SUSHI.ARPA Still need stanford speaker for 10/11/85 bats
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 09:03:02 PDT
Date: Tue 1 Oct 85 08:55:50-PDT
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: Still need stanford speaker for 10/11/85 bats
To: aflb.su@SU-SUSHI.ARPA
cc: ragde%ucbernie@UCB-VAX.ARPA
No one from Stanford has volunteered to speak at BATS in Berkeley on 10/11.
I'm still waiting...
-------
∂01-Oct-85 0922 @SU-SCORE.ARPA:SHORTLIFFE@SUMEX-AIM.ARPA Re: topics for prob. theory course
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 09:22:36 PDT
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 1 Oct 85 09:18:36-PDT
Date: Tue 1 Oct 85 09:21:59-PDT
From: Ted Shortliffe <Shortliffe@SUMEX-AIM.ARPA>
Subject: Re: topics for prob. theory course
To: MAYR@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
In-Reply-To: <12147462849.29.MAYR@SU-SCORE.ARPA>
Office: Room TC-135, Stanford Med Center; Phone: (415) 497-6979
Message-ID: <12147669580.39.SHORTLIFFE@SUMEX-AIM.ARPA>
I am VERY interested to hear about this development. We require a
course in probability (Stat 116 or EES 221) for the MS or PhD in Medical
Information Sciences, and there has been some dissatisfaction with the way
those courses relate both to the DA (decision analysis) portions of our
curriculum and to the CS requirements which form the bulk of the required
courses. I sent out your message to our current students, including those
who have taken Stat 116 or EES 221, and asked them to make suggestions based
on their experiences in those courses. Will forward you the responses that
I receive. One of our better students, with a particular interest in
math and statistics (working on problems of evidential reasoning for expert
systems) has already replied and I'll forward his message to you right now.
Please keep me informed on how this develops. We will almost
certainly change our required curriculum to include this new course if it
is indeed implemented.
Regards,
Ted Shortliffe
-------
∂01-Oct-85 1017 CLT Seminar on Logic and the Foundations of Mathematics
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA, su-bboards@SU-AI.ARPA
Speaker: Prof. Shaughan Lavine, Dept. of Mathematics, Stanford
Title: Prewellordering and the generalized reduction property.
Time: Monday, Oct.7, 4:15-5:30 P.M.
Place: Room 383N (faculty lounge, 3d floor, Math. Bldg.).
S. Feferman
PS
If you see this message on one of the bulletin boards and
would like to be on the regular mailing list for logic
and theory of computation type announcements
or
if you receive this message in your electronic mail box and
would like to be removed from the mailing list
then
send a message to CLT@SU-AI.
∂01-Oct-85 1039 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar on Logic and the Foundations of Mathematics
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 10:30:16 PDT
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 1 Oct 85 10:29:26-PDT
Date: 01 Oct 85 1017 PDT
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: Seminar on Logic and the Foundations of Mathematics
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA, su-bboards@SU-AI.ARPA
Speaker: Prof. Shaughan Lavine, Dept. of Mathematics, Stanford
Title: Prewellordering and the generalized reduction property.
Time: Monday, Oct.7, 4:15-5:30 P.M.
Place: Room 383N (faculty lounge, 3d floor, Math. Bldg.).
S. Feferman
PS
If you see this message on one of the bulletin boards and
would like to be on the regular mailing list for logic
and theory of computation type announcements
or
if you receive this message in your electronic mail box and
would like to be removed from the mailing list
then
send a message to CLT@SU-AI.
∂01-Oct-85 1150 ullman@su-aimvax.arpa meeting tomorrow
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 11:50:24 PDT
Received: by su-aimvax.arpa with Sendmail; Tue, 1 Oct 85 11:47:21 pdt
Date: Tue, 1 Oct 85 11:47:21 pdt
From: Jeff Ullman <ullman@diablo>
Subject: meeting tomorrow
To: nail@diablo
Let's meet at 11AM.
Therer is no agenda, but I have some funny stories
to tell, and perhaps other topics will come up.
∂01-Oct-85 1227 avg@su-aimvax.arpa Re: meeting tomorrow
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 12:23:12 PDT
Received: by su-aimvax.arpa with Sendmail; Tue, 1 Oct 85 12:20:19 pdt
Date: Tue, 1 Oct 85 12:20:19 pdt
From: Allen VanGelder <avg@diablo>
Subject: Re: meeting tomorrow
To: nail@diablo, ullman@diablo
I can continue on NC/P and present the non-trivial NC example and or the
P-complete example.
∂01-Oct-85 1340 HAUNGA@SUMEX-AIM.ARPA Title for Siglunch - Friday Oct 4
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 13:40:15 PDT
Date: Tue 1 Oct 85 13:37:33-PDT
From: Ana Haunga <HAUNGA@SUMEX-AIM.ARPA>
Subject: Title for Siglunch - Friday Oct 4
To: siglunch@SUMEX-AIM.ARPA
Message-ID: <12147716104.31.HAUNGA@SUMEX-AIM.ARPA>
This week's SIGLunch talk is "Introspection" by Mike Genesereth.
The abstract will follow. SIGLunch is held in the Chemistry Gazebo
at 12:05-1:00.
-----a
-------
∂01-Oct-85 1525 LIBRARY@SU-SCORE.ARPA Socrates: SELECT 9 for Technical Reports
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 15:25:07 PDT
Date: Tue 1 Oct 85 15:21:26-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: SELECT 9 for Technical Reports
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12147735017.15.LIBRARY@SU-SCORE.ARPA>
Now that the new version of Socrates is up, I hope you will take advantage
of the Technical Reports file which has been added. The Technical Reports
file contains records from all of the science libraries. However a majority
of the records currently in the file are records from the technical reports
collection in the Math/CS Library. Our printed index in the library is
no longer up to date for our collection and the file on Socrates should
be used to determine what we have. New reports are being added to the
Socrates file directly and printed indexes will not be generated. However
we are continuing to announce our New Reports List online through the
Bulletin Board.
The Technical Reports file is a separate file on Socrates and is not
included in the Catalog Headings file. To call up the Technical Reports
file you can say SELECT Technical Reports or SELECT 9. Once you are
in the file, you can search the file as you would any other file on
Socrates either in the GUIDED or COMMANS modes. You may also BROWSE
authors, subjects etc.
If you have any comments or questions about the Technical Reports file or
other Socrates issues, I would be interested in hearing them. You may
make suggestions directly to the group developing Socrates by using
the SUGGEST command. Anyone needing a Socrates account can come by the
library to file out the form and pick up an account number.
Harry Llull
-------
∂01-Oct-85 1600 RICHARDSON@SU-SCORE.ARPA Pre-Colloquium Cookie Time
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 16:00:31 PDT
Date: Tue 1 Oct 85 15:47:30-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Pre-Colloquium Cookie Time
To: csd@SU-SCORE.ARPA
Message-ID: <12147739761.11.RICHARDSON@SU-SCORE.ARPA>
CS 500 Pre-Colloquium Cookie Time is now in progress in the student lounge
of Margaret Jacks Hall.
-------
∂01-Oct-85 1636 MARJORIE@SU-CSLI.ARPA key
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 16:36:38 PDT
Date: Tue 1 Oct 85 16:34:12-PDT
From: Marjorie Maxwell <MARJORIE@SU-CSLI.ARPA>
Subject: key
To: folks@SU-CSLI.ARPA
Has anyone lost a key - if so check with me at G-4.
Marj
-------
∂01-Oct-85 1723 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Monday Planlunch Reminder!
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 17:22:47 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 1 Oct 85 17:15:45-PDT
Date: Sun 29 Sep 85 19:05:29-PDT
From: LANSKY@SRI-AI.ARPA
Subject: Monday Planlunch Reminder!
To: aic-associates@SRI-AI.ARPA, folks@SU-CSLI.ARPA, mugs@SUMEX-AIM.ARPA,
val@SU-AI.ARPA, phayes@SRI-KL.ARPA, carnese@SRI-KL.ARPA,
alpert@SU-SUSHI.ARPA, frayman@SUMEX-AIM.ARPA, dmrussell@XEROX.ARPA,
araya@XEROX.ARPA, frayman@XEROX.ARPA, suchman@XEROX.ARPA, weld@XEROX.ARPA,
mittal@XEROX.ARPA, dekleer@XEROX.ARPA, trigg@XEROX.ARPA
PROCESSES, SIMULTANEITY AND CAUSALITY
Michael P. Georgeff
Artificial Intelligence Center
SRI International
11:00 AM, MONDAY, September 30
SRI International, Building E, Room EJ228 (new conference room)
The notion of process is essential for reasoning about the behavior of
multiple agents or single agents in dynamic worlds. In this talk, we
show why reasoning about process is so important, and contrast this
with other approaches in AI which are primarily based on the allowable
behaviors of agents. An algebra of processes based on events is given.
We then show how events can be represented as changes of world state,
and how state properties can be inferred from the model. Interestingly,
no STRIPS-like assumption is involved in the definition of events, thus
allowing a proper model-theoretic semantics. One of the most important
features of the model is a hiding operation. This provides an abstraction
capability that can be used to avoid the combinatorial explosion
typical of other AI approaches. Finally, we introduce a notion of
causality between events and processes. This, together with the
notion of simultaneous actions and hiding operations, allows us to
avoid most of the problems associated with the frame problem.
-------
∂01-Oct-85 1726 POLLARD@SU-CSLI.ARPA new entity
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 17:26:10 PDT
Date: Tue 1 Oct 85 17:23:12-PDT
From: Carl Pollard <POLLARD@SU-CSLI.ARPA>
Subject: new entity
To: folks@SU-CSLI.ARPA
Lucretia Claire Pollard was born at 1:39 Saturday afternoon at Stanford
Hospital. 9 pounds 2 ounces, 21-1/2 inches long, and doing fine. Parents
& big sister doiing fine too (but our recollections of a night's sleep
grow dimmer by the hour).
-------
∂02-Oct-85 0920 JOHN@SU-CSLI.ARPA Wheels for Wheels
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 09:20:02 PDT
Date: Wed 2 Oct 85 09:17:16-PDT
From: John Perry <JOHN@SU-CSLI.ARPA>
Subject: Wheels for Wheels
To: Folks@SU-CSLI.ARPA
Thanks to the hard work of Jamie Marks and David Brown, we have solved
our transportation needs to and from the Inner Quad for this era.
There are now 10 beautifully painted bicyles -- see if you can pick
them out -- available for trips between CSLI and the Philosophy/
Linguistics corner. The following instant traditions govern the use
of these bicyles:
1. Any CSLI-ite can get a key that will work on the locks of all of
these bikes from Bach-Hong.
2. Anyone may ride any CSLI bike parked at Ventura to the Philosophy/
Linguistics corner with no responsibility to return it.
3. Vice versa.
4. One can ride a CSLI bike to some other part on Campus but has the
responsibility of returning it to one of the above areas the same
day.
5. Anyone who takes a CSLI bike off Campus is behaving outrageously
and other CSLI-ites who see this happening should throw things.
Corollary, you cannot be sure when you ride a CSLI bike to Ventura or
to the Philosophy/Linguistics corner for some event, that it will be
waiting for you after the event, i.e., plan accordingly.
After we have had some experience with this we will consider changes
in the rules, if necessary. Let us know how it is working.
Report repair problems to Tom Yamarone or Jamie Marks.
We are negotiating for 10 Alfa Romeos to be painted similarly for
transportation between Ventura and SRI and PARC.
John Perry
-------
∂02-Oct-85 1030 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ucbernie.Berkeley.EDU
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 10:30:40 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 2 Oct 85 10:27:21-PDT
Received: from UCB-VAX.ARPA by SU-SCORE.ARPA with TCP; Wed 2 Oct 85 10:25:10-PDT
Received: by UCB-VAX.ARPA (5.28/5.11)
id AA18296; Wed, 2 Oct 85 08:17:05 PDT
Received: by ucbernie.ARPA (4.24/5.11)
id AA19894; Wed, 2 Oct 85 08:17:00 pdt
Date: Wed, 2 Oct 85 08:17:00 pdt
From: karp@ucbernie.Berkeley.EDU (Richard Karp)
Message-Id: <8510021517.AA19894@ucbernie.ARPA>
To: aflb.all@su-score.arpa
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley (415)642-0143
COMPUTATIONAL COMPLEXITY SEMINARS
Wednesday, October 2 2:00 MSRI Lecture Hall
Lenore Blum
A Tutorial on Karmarkar's Algorithms
MSRI-EVANS WEDNESDAY LECTURE
Wednesday, October 2 4:15 60 Evans
Juris Hartmanis
On The Structure of Feasible Computations
Thursday, October 3 4:00 MSRI Lecture Hall
Neil Immerman
Expressibility and First-Order Reductions
Tuesday, October 8 2:00 MSRI Lecture Hall
Helmut Alt
Simulation of Idealized Models of Parallel Computers on (More) Realistic Ones
Tuesday, October 8 4:00 MSRI Lecture Hall
Eric Kostlan
Complexity Theory of Numerical Linear Algebra
Week of October 14-18
Workshop on Computation in Algebra and Number Theory
Schedule to be announced.
∂02-Oct-85 1248 admin@ucbcogsci.Berkeley.EDU UCB Cognitive Science Seminar--Oct. 8 (Terry Winograd, Stanford)
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 12:48:36 PDT
Received: by UCB-VAX.ARPA (5.28/5.11)
id AA23805; Wed, 2 Oct 85 12:45:01 PDT
Received: by ucbcogsci.ARPA (5.5/5.7)
id AA22854; Wed, 2 Oct 85 12:46:31 PDT
Date: Wed, 2 Oct 85 12:46:31 PDT
From: admin@ucbcogsci.Berkeley.EDU (Cognitive Science Program)
Message-Id: <8510021946.AA22854@ucbcogsci.ARPA>
To: cogsci-friends@ucbcogsci.Berkeley.EDU
Subject: UCB Cognitive Science Seminar--Oct. 8 (Terry Winograd, Stanford)
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, October 8, 11:00 - 12:30
PLACE 240 Bechtel Engineering Center
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Terry Winograd, Computer Science, Stanford University
TITLE: "What Can Cognitive Science Tell Us About Computers?"
Much work in cognitive science rests on the assumption that
there is a common form of "information processing" that under-
lies human thought and language and that also corresponds to
the ways we can program digital computers. The theory should
then be valid both for explaining the functioning of the
machines (at whatever level of "intelligence") and for under-
standing how they can be integrated into human situations and
activities.
I will argue that theories like those of current cognitive
science are based on a "rationalistic" tradition, which is
appropriate for describing the mechanics of machine operation,
but is inadequate for understanding human cognitive activity
and misleading as a guide to the design and application of
computer technology. The emphasis will be on looking at
alternatives to this tradition, as a starting point for under-
standing what computers really can do.
---------------------------------------------------------------
UPCOMING TALKS
Oct 15: Ron Kaplan, Xerox PARC
Oct 22: Lotfi Zadeh, Computer Science, UCB
Oct 29: Mardi Horowitz, Psychiatry, UCSF
Nov 5: Edward Zalta, CSLI, Stanford
Nov 12: Robert Wilensky, Computer Science, UCB
Nov 19: Richard Alterman, Computer Science, UCB
Nov 26: Eve Clark, Linguistics, Stanford
Dec 3: Bernard Baars, Langley Porter, UCSF
* * * * *
ELSEWHERE ON CAMPUS
Edward De Avila, of Linguametrics, Inc., will be speaking on
"The Status of Language Minority Students in the U.S.: Scho-
lastic Performance in Math and Science" on Monday, October 7,
1985, at 4:10 p.m. in 2515 Tolman Hall, UCB.
Boris Gasparov, of the UCB Slavic Languages and Literatures
Dept., will be speaking on "Stylistic `Shifters' in Russian"
on Tuesday, Oct. 8, 1985, at 8:00 p.m. in the Tilden Room,
Student Union Bldg., UCB.
William Cole, Cognitive Science, will be speaking on "Medical
Cognitive Graphics" on Friday, October 11, 1985, at 4:00 p.m.
in the Beach Room, 3105 Tolman Hall, UCB.
--------------------------------------------------------------
∂02-Oct-85 1248 @SU-CSLI.ARPA:admin@ucbcogsci.Berkeley.EDU UCB Cognitive Science Seminar--Oct. 8 (Terry Winograd, Stanford)
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 12:48:39 PDT
Received: from UCB-VAX.ARPA by SU-CSLI.ARPA with TCP; Wed 2 Oct 85 12:45:30-PDT
Received: by UCB-VAX.ARPA (5.28/5.11)
id AA23805; Wed, 2 Oct 85 12:45:01 PDT
Received: by ucbcogsci.ARPA (5.5/5.7)
id AA22854; Wed, 2 Oct 85 12:46:31 PDT
Date: Wed, 2 Oct 85 12:46:31 PDT
From: admin@ucbcogsci.Berkeley.EDU (Cognitive Science Program)
Message-Id: <8510021946.AA22854@ucbcogsci.ARPA>
To: cogsci-friends@ucbcogsci.Berkeley.EDU
Subject: UCB Cognitive Science Seminar--Oct. 8 (Terry Winograd, Stanford)
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, October 8, 11:00 - 12:30
PLACE 240 Bechtel Engineering Center
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Terry Winograd, Computer Science, Stanford University
TITLE: "What Can Cognitive Science Tell Us About Computers?"
Much work in cognitive science rests on the assumption that
there is a common form of "information processing" that under-
lies human thought and language and that also corresponds to
the ways we can program digital computers. The theory should
then be valid both for explaining the functioning of the
machines (at whatever level of "intelligence") and for under-
standing how they can be integrated into human situations and
activities.
I will argue that theories like those of current cognitive
science are based on a "rationalistic" tradition, which is
appropriate for describing the mechanics of machine operation,
but is inadequate for understanding human cognitive activity
and misleading as a guide to the design and application of
computer technology. The emphasis will be on looking at
alternatives to this tradition, as a starting point for under-
standing what computers really can do.
---------------------------------------------------------------
UPCOMING TALKS
Oct 15: Ron Kaplan, Xerox PARC
Oct 22: Lotfi Zadeh, Computer Science, UCB
Oct 29: Mardi Horowitz, Psychiatry, UCSF
Nov 5: Edward Zalta, CSLI, Stanford
Nov 12: Robert Wilensky, Computer Science, UCB
Nov 19: Richard Alterman, Computer Science, UCB
Nov 26: Eve Clark, Linguistics, Stanford
Dec 3: Bernard Baars, Langley Porter, UCSF
* * * * *
ELSEWHERE ON CAMPUS
Edward De Avila, of Linguametrics, Inc., will be speaking on
"The Status of Language Minority Students in the U.S.: Scho-
lastic Performance in Math and Science" on Monday, October 7,
1985, at 4:10 p.m. in 2515 Tolman Hall, UCB.
Boris Gasparov, of the UCB Slavic Languages and Literatures
Dept., will be speaking on "Stylistic `Shifters' in Russian"
on Tuesday, Oct. 8, 1985, at 8:00 p.m. in the Tilden Room,
Student Union Bldg., UCB.
William Cole, Cognitive Science, will be speaking on "Medical
Cognitive Graphics" on Friday, October 11, 1985, at 4:00 p.m.
in the Beach Room, 3105 Tolman Hall, UCB.
--------------------------------------------------------------
∂02-Oct-85 1305 CHEADLE@SU-SCORE.ARPA Hopeful Ph.D. Grads
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 13:05:43 PDT
Date: Wed 2 Oct 85 13:00:45-PDT
From: Victoria Cheadle <CHEADLE@SU-SCORE.ARPA>
Subject: Hopeful Ph.D. Grads
To: faculty@SU-SCORE.ARPA
Office: Margaret Jacks 258, 497-1519
Message-ID: <12147971551.26.CHEADLE@SU-SCORE.ARPA>
Listed below are the names of the Ph.D. students in the Computer Science
Department who plan to graduate sometime in the next year.
@begin(verbatim)
Abadi, Martin
Anderson, Richard
Asente, Paul
Beigel, Richard
Celoni SJ, James
Demetrescu, Stefan
Foulser, David
Feigenbaum, Joan
Fraley, Christina
Kenniston, Michael
Lowry, Michael
Mackinlay, Jock
Mitchell, Chad
Mogul, Jeffrey
Moses, Yoram
Russell, Stuart
Spreitzer, Michael
Tang, Wei Pai
Theimer, Marvin
Treitel, Richard
VanGelder, Allen
Weening, Joseph
Winslett, Marianne
@end(verbatim)
I thought you find this information useful.
Victoria
-------
∂02-Oct-85 1323 LIBRARY@SU-SCORE.ARPA Socrates: Display to account--SUSHI problem
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 13:23:03 PDT
Date: Wed 2 Oct 85 13:19:14-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: Display to account--SUSHI problem
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12147974915.33.LIBRARY@SU-SCORE.ARPA>
John Lamping has brought to my attention that Display To Account on Socrates
does not work. He has send a message to the Socrates people about this.
Display To Account does work with SCORE and I assume other computers.
Are users of Socrates on other computers having problems with the Display
To Account command?
Harry Llull
-------
∂02-Oct-85 1352 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 13:52:36 PDT
Date: Wed 2 Oct 85 13:49:13-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12147980373.33.LIBRARY@SU-SCORE.ARPA>
Ada For Specification: Possibilities And Limitations. ed. by Goldsack.
Cambridge Univ. Press. QA76.73.A35A284 1985
Combinatorics For Computer Science. by Gill Williamson. Computer Science
Press. QA164.W55 1985
The Second Scandinavian Conference On Image Analysis. Finland 1981.
TA1632.S27 1981
Surveys In Combinatorics 1985 Invited Papers for the 10th British
Combinatorial Conf. ed. by Ian Anderson. Cambridge Univ. Press.
QA164.B74 1985.
TEX For Scientific Documentation. Proceedings of the first European Conf.
1985 Italy. Z253.4T47E97 1985
Progress In Artificial Intelligence. ed. by L. Steels and J.A. Campbell.
Ellis Horwood Series AI. Q335.P76 1985
Introduction To Computer Science Using The Turing Programming Language.
by R.C. Hold and J.N.P. Hume. Reston Publ. QA76.H623 1984.
Dynamical Systems And Cellular Automata. ed. by J. Demongeot, E. Goles,
and M. Tchuente. Academic Press. QA267.5C45D96 1985
Numerical Methods For Scientific And Engineering Computation. by M.K.Jain
S.R. Klyengar and R.K Jain. Halsted Press Book. QA297.J28 1985.
Programming With APSE Software Tools. By Roy Freedmand. Petrocelli Books.
QA76.73A35F74.
The Analysis and Design Of Computer-Based Information Systems. by Joan
Nordbotten. Univ. of Bergen. QA76.9.S88N67 1985.
Application Systems in A.P.L.; How to build them right. by Gibson, Levine,
Metzger. I.P. Sharp Associates. LTD. QA76.73.A27G53 1985.
Writing and Analyzing Effective Computer System Documentation. by Ann
Stuart. Holt, Rinehart and Winston. QA76.9.D6S78 1984.
Forth; Tools and Applications by Gary Feierbach and Paul Thomas.
QA76.73.F24F45 1985.
The Biology Of Computer Life; Survival, Emotion and Free Will. Geoff
Simons, National Computing Centre, England. Birkhauser. QA76.9.P75S57
1985.
Back To Basic; The History, Corruption, and Future of the Language.
by Kemeny and Kurtz. QA76.73.B3K44 1985
H. Llull
-------
∂02-Oct-85 1410 LIBRARY@SU-SCORE.ARPA Math/CS Library: New Reference Books--Guide to CS literature, Industrial Robotics Handbook, Computer-Readable Databas
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 14:10:21 PDT
Date: Wed 2 Oct 85 14:06:26-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library: New Reference Books--Guide to CS literature, Industrial Robotics Handbook, Computer-Readable Databases, German/English Dict.
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12147983508.33.LIBRARY@SU-SCORE.ARPA>
Computer Information Directory. compiled and ed. by Darlen Myers
Hilebrandt. Revised and expanded. 1985 Z5640.H54 1985
Excellent up-to-date guide to information resouces in Computer Science.
Handbook Of Industrial Robotics. by ed. Shimon Y. Nof. with a forward by
Isaac Asimov. 1985. 1358 pages. TS191.8H36 1985.
Data Systems Dictionary. English/German, German/English. QA76.15.B74 1985.
Computer Readable Databases; A directory and data sourcebooks. two volumes
vol. 1 Business, Law, Humanities, Socieal Sciences Vol. 2 Science,
Technology and Medicine. Martha Williams Editor-in-chief.
Z699.22C66 1985
H. Llull
-------
∂02-Oct-85 1524 STUCKY@SU-CSLI.ARPA Bibliography Files
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 15:24:02 PDT
Date: Wed 2 Oct 85 15:20:34-PDT
From: Susan Stucky <Stucky@SU-CSLI.ARPA>
Subject: Bibliography Files
To: folks@SU-CSLI.ARPA
Dear All,
A number of folks met yesterday to talk about the feasibility of setting
up bibliography files that would be accessible to everyone for
formatting in Latex or Scribe. The idea is to keep files in a public directory
that can be used (though each subject file is maintained by a "Keeper
who is interested enough to enter materials sent to him/her and check
for consistency.) We decided that such files would be feasible and are
presently working out the details.
The following files and keepers are in the works:
Pragmatics: Dietmar Zaefferer
Phil. of Lg./Logic/Mathematics: Etchemendy, Menzel
Semantics: Link
Syntax: Rooth (and Hans if we can get him interested)
These are flexible (we decided on subject files rather than big ones
even though it may be that Latex cannot access more than one.) If you
are interested in maintaining a file, let me know.
If you are interested in getting the mail relevant to this endeavor,
send a message to Requests. This will be the last public message until
the system is up and running. If you are interested in the mail that has
been sent already or if yu have further questions, send a message to Stucky.
-Susan
-------
∂02-Oct-85 1713 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #20
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 17:13:15 PDT
Date: 2 Oct 85 1656-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #20
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 2 Oct 1985 Volume 1 : Issue 20
Today's Topic:
Second PARSYM Survey: Data Abstractions for Parallel Programming
----------------------------------------------------------------------
Date: Wed, 2 Oct 1985 16:50 PDT
From: DAVIES@SUMEX-AIM.ARPA
Subject: Second PARSYM Survey
Data Abstractions for Parallel Programming
In this Second PARSYM Survey, I would like to find out what data
abstractions people find useful or are now developing to support
parallel computation. From what I've seen, most published work is
devoted to control structures and communication rather than to data
structures. To illustrate what I mean by "data abstractions for
parallel programming", I'll use some examples from multiprocessing
Lisp implementations.
Speaking in dichotomies, there are two approaches to introducing
parallelism to Lisp. The first -- the control structure approach --
is exemplified by QLISP's QLET and Multilisp's PCALL: parallelism is
invoked through the lambda binding or function calling control
constructs. QLET computes the values of LET parameters in parallel;
PCALL computes the arguments to a function in parallel. (Both QLISP
-- formerly QLAMBDA -- and Multilisp are described in the Proceedings
of the 1984 Lisp and Functional Programming Conference.)
The second approach is what I call the data structure approach, and is
exemplified by the QLAMBDA construct in QLISP or the FUTURE construct
in Multilisp or the XECTOR on the Connection Machine (see Danny
Hillis's excellent new book "The Connection Machine" from MIT Press).
These constructs allow the programmer to deal with processes as first
class objects, and hence build structures of processes. Gabriel and
McCarthy created pipelines in QLISP by stringing together QLAMBDA
processes with the output of one feeding the input of the next. The
pipeline object so created is also a first class object which can be
passed around to provide pipeline processing whereever needed. A
XECTOR is a generalized vector. It can be used to represent
structures of data as we normally think of them or structures of
processes (or rather a combination of the two since the Connection
Machine closely identifies data and processes).
I don't want to use the questionnaire to exhaust all possible answers
to itself, but I will point out one more published example of a data
structure -- of quite a different type -- specifically created for
parallel computing. This is the FRONS of Friedman and Wise's IAP
system (described in Filman and Friedman's book Coordinated
Computing). A FRONS is a list the order of whose elements is
determined by the order in which they were computed. It's roughly a
stream which freezes as the objects are created: the identity of the
CAR of a FRONS is nondeterministic until it is accessed, but remains
the same forever once it is accessed.
Please fill in the following questionnaire and return it to
PARSYM-Survey@SUMEX-AIM.ARPA. As with the first survey, I plan to
distribute to PARSYM a summary of the replies as well as the text of
the replies themselves. If you would rather not have your reply
distributed in full, please let me know. Replies are particularly
welcomed from those whose systems I've mentioned: I'd appreciate any
clarifications. Many thanks to Vineet Singh for help in formulating
the questionnaire.
Second PARSYM Survey: Data Abstractions
(Replies to PARSYM-Survey@SUMEX-AIM.ARPA)
1. Are you using or have you developed data structures or
abstractions specialized for parallel computing? Please
describe.
2. In particular, do you use specialized data abstractions to
represent configurations of multiple processes? Please
describe.
3. Do you use specialized data structures, a la FRONS, for
representing non-deterministic collections of data? Please
describe.
4. What are some useful references on the topic of data abstraction
in parallel computing (including your own)?
5. Other comments welcome.
------------------------------
End of PARSYM Digest
********************
∂02-Oct-85 1726 EMMA@SU-CSLI.ARPA addendum to the newsletter
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 17:26:06 PDT
Date: Wed 2 Oct 85 17:25:28-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: addendum to the newsletter
To: friends@SU-CSLI.ARPA
Tel: 497-3479
Re: the tentative Fall calendar
Each project is responsible for ONE colloquium sometime during the
two to three week period listed.
-Emma Pease
-------
∂02-Oct-85 1744 EMMA@SU-CSLI.ARPA Newsletter October 3, No. 48
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 17:43:59 PDT
Date: Wed 2 Oct 85 16:55:24-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter October 3, No. 48
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
October 3, 1985 Stanford Vol. 2, No. 48
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, October 3, 1985
12 noon TINLunch
Ventura Hall ``Idealized Cognitive Models'' and ``Metonymic Models''
Conference Room Sections 4, 5 of ``Women, Fire, and Dangerous Things''
by George Lakoff
Discussion led by Douglas Edwards
2:15 p.m. CSLI Seminar
Redwood Hall ``Notes from the STASS Underground''
Room G-19 David Israel, CSLI and SRI
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, October 10, 1985
12 noon TINLunch
Ventura Hall ``Artificial Intelligence Meets Natural Stupidity''
Conference Room by Drew McDermott
Discussion led by Roland Hausser, U. of Munich
2:15 p.m. CSLI Seminar
Redwood Hall ``Ontology and Intensionality''
Room G-19 Edward Zalta, CSLI
Discussion led by John Perry
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
TENTATIVE FALL SCHEDULE FOR THURSDAYS
THURSDAY SEMINARS
Date Person or Group responsible
10-3 Situation Theory and Situation Semantics
10-10 Zalta
10-17 Sells
10-24 Discourse, Intention and Action
10-31 Foundations of Document Preparation
11-7 Phonology and Phonetics
11-14 Finite State Morphology
11-21 Computational Models of Spoken Language
12-5 Winograd
!
Page 2 CSLI Newsletter October 3, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
THURSDAY COLLOQUIA
10-3 to 10-17: Situation Theory and Situation Semantics
10-24 to 11-7: Discourse, Intention and Action
11-14 to 11-20: Phonology & Phonetics, Finite State Morphology, &
Computational Models of Spoken Language
11/21 Joe Traub, CS Dept., Columbia
←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S SEMINAR
``Ontology and Intensionality''
The foundations of semantics require more than just a theory of
properties, relations, and propositions. Such theories do show that
logically equivalent relations and propositions are not necessarily
identical, but they do not provide us with an explanation of modality
and tense (for which we need something like worlds and times), nor
with an explanation of the truth conditions, entailments, and
substitutivity failures involving codesignative names and descriptions
of important varieties of intensional sentences (for which we need
something like intentional objects). The theory which I have been
developing has logical axioms which generate properties, relations,
and propositions, and proper axioms which generate abstract
individuals, some of which have just the features worlds have and some
of which can help us explain intensionality by serving as intentional
objects. In the seminar, I'll show how to extend the theory to define
times and account for the many similarities between worlds and times.
Then I'll show that, given this ontology, the traditional
understanding of intensionality must be revised and that certain
classic puzzles involving modality and descriptions have a simple
solution. --Ed Zalta
←←←←←←←←←←←←
LOGIC LUNCH
On Mondays there will be an informal brown bag logic lunch in the
Philosophy Lounge, building 90, from 12 to 1, starting October 7. If
you are interested in logic, please come any time. Send questions to
Jon Barwise (barwise@su-csli).
←←←←←←←←←←←←
LOGIC SEMINAR
The Logic Seminar will resume October 7 in the mathematics seminar
room. It will meet every Monday at 4:15. Contact Sol Feferman
(SF@su-csli) for details. Information on the first seminar follows.
``Prewellordering and the Generalized Reduction Property''
Prof. Shaughan Lavine, Dept. of Mathematics, Stanford
Monday, Oct. 7, 4:15-5:30 P.M.
Room 383N (faculty lounge, 3d floor, Math. Bldg.).
-------
∂03-Oct-85 0750 HAUNGA@SUMEX-AIM.ARPA title and abstract for SIGLUNCH Friday 4th.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 07:50:50 PDT
Date: Thu 3 Oct 85 07:50:26-PDT
From: Ana Haunga <HAUNGA@SUMEX-AIM.ARPA>
Subject: title and abstract for SIGLUNCH Friday 4th.
To: Siglunch@SUMEX-AIM.ARPA
Message-ID: <12148177201.13.HAUNGA@SUMEX-AIM.ARPA>
Here is the title and abstract for tomorrow's SIGLUNCH.
Introspection
Michael R. Genesereth
Logic Group
Knowledge Systems Laboratory
Stanford University
Abstract: Introspection is a significant part of human mental
activity. We introspect whenever we think about how to solve problem,
whenever we decide what information we need to solve a problem,
whenever we decide that a problem is unsolvable.
By its nature, the process of introspection involves both descriptive
and prescriptive metaknowledge. Over the past years, logicians and AI
researchers have devoted considerable attention to autoepistemic
sentences (involving terms like KNOW). By comparison, little attention
has been paid to prescriptive metaknowledge (involving terms like OUGHT).
This talk introduces a semantics for such knowledge in the form of
constraints on the process of problem solving. It demonstrates the
computational advantages of introspection, and analyzes the
computational fidelity and cost of various introspective
architectures. Finally, it discusses the potential for practical
application in logic programming and building expert systems.
-------
-------
-------
∂03-Oct-85 1038 NILSSON@SU-SCORE.ARPA 5-year Plan
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 10:30:41 PDT
Date: Thu 3 Oct 85 10:26:24-PDT
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: 5-year Plan
To: faculty@SU-SCORE.ARPA
Message-ID: <12148205595.27.NILSSON@SU-SCORE.ARPA>
I am in the process of writing a "five-year plan" for the Department.
This plan has been requested by Dean Gibbons and will form a part of the
plan for Engineering requested by Provost Jim Rosse. The plan will
play a particularly important role in future events for the CSD. It will
influence how planned new chairs are distributed within the SOE; it will
influence space decisions regarding the new CSD building; it will influence
new faculty position assignments and other resource allocations. One
important component of the plan will involve the resource needs projected
for the new undergraduate major. So, in developing this plan, we need
to think carefully about what we want the department to be like during the
next five years and beyond. Do we have weaknesses that need to be corrected
by adding faculty in particular areas? What do we think about how research
will be done (more research associates per faculty member and things like
that)? I'm not even sure we have all the right questions yet, but I need
to get some preliminary draft material written in the next few weeks. So--
please send me any comments you might have that you think might be helpful
in this process--either questions we need to ask ourselves or answers.
I will certainly circulate drafts of anything I write before they ascend up
the system. Thanks, -Nils
-------
∂03-Oct-85 1236 WINOGRAD@SU-CSLI.ARPA Environments group - Monday 12:00pm
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 12:36:52 PDT
Date: Thu 3 Oct 85 12:35:46-PDT
From: Terry Winograd <WINOGRAD@SU-CSLI.ARPA>
Subject: Environments group - Monday 12:00pm
To: friends@SU-CSLI.ARPA
--sorry for the separate distribution but this didn't make it
in time for the newsletter this week. --t
----------------------
COMING WEEK (Monday Oct. 7): 12:00 to 1:15 in the Ventura trailer
classroom (NOTE NEW REGULAR TIME), David Levy (Xerox PARC and CSLI)
will describe his work on a theoretical foundation for document
preparation environments.
------
PREVIOUS WEEK (Sept. 30): At the first meeeting of the environments
group we set out the general directions for our discussions. We
identified some major dimensions along which to compare and examine
environments and made an initial list of examples that might be
presented. This list is very sketchy -- the random result of what
happened to come up in conversation. We are eager for further details
and suggestions (either systems for general consideration, or about
which specific people would like to talk):
Programming environments: Interlisp, Smalltalk, Cedar, [all 3 Xerox],
(Linton) [Berkeley/Stanford], Gandalf [CMU], Mentor [INRIA], ZetaLisp
[Symbolics], Kee [Intellicorp], HPRL, HPLisp [last 2 Hewlett-Packard]
Grammar development environments: LFG [CSLI], HPSG [HP], BLT [CSLI],
Specification environments: Aleph [CSLI], (Balzer)[ISI]
Language development environments: MUIR [CSLI]
Document preparation environments: (Levy) [CSLI], Notecards [Xerox]
Data access and manipulation envrionments: ?
Mathematical and logical deduction environments: MACSYMA [MIT], FOL
[Stanford]
There is a variety of application areas not as central to CSLI concerns,
but in which enviornments are built. These include VLSI design,
CAD/CAM, image manipulation, mail systems, etc. In addition, most
operating systems take on the functions of an environment, either for
use outside of applications programs or as a base within them.
So-called "intelligent agents" are one attempt to provide a uniform
environment for a particular user interacting with multiple systems.
For each kind of environment there are specific problems dealing with
the particular structures being worked with (programs, proofs, grammars,
formatted documents, etc.). There is also a framework of common
problems having to do with the basic structure of items being
manipulated (text, trees, databases, etc.), their representation on a
screen or hardcopy, interfaces for operating through that
representation, storage on one or more devices, consistency between
aspects (e.g., source and compiled code, specifications and proofs),
change over time (versions, releases, etc.), coordination of access
among a group, etc.
Our plan is to address the basic conceptual issues by looking at one
particular envrionment or group of related environments in each session.
Next week's topic will be a discussion of the theoretical foundations of
document preparation, by David Levy.
-------
∂03-Oct-85 1354 @SU-SUSHI.ARPA:broder@decwrl.ARPA Plane ticket swap wanted
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 13:53:55 PDT
Received: from decwrl.ARPA by SU-SUSHI.ARPA with TCP; Thu 3 Oct 85 13:49:59-PDT
Received: from magic.ARPA by decwrl.ARPA (4.22.01/4.7.34)
id AA04315; Thu, 3 Oct 85 13:53:14 pdt
Received: by magic.ARPA (4.22.01/4.7.34)
id AA26503; Thu, 3 Oct 85 13:53:41 pdt
From: broder@decwrl.ARPA (Andrei Broder)
Message-Id: <8510032053.AA26503@magic.ARPA>
Date: 3 Oct 1985 1353-PDT (Thursday)
To: aflb.all@sushi.ARPA
Cc:
Fcc: sent
Subject: Plane ticket swap wanted
I have a ticket to Portland on Oct 19 (Sat) at 12:20 p.m. from San Jose
on Air-Cal. I'd like to swap it for an earlier flight the same day,
either from San Jose or from San Francisco. Anyone interested? -
Thanks, Andrei
∂04-Oct-85 1014 ACUFF@SUMEX-AIM.ARPA Symbolics Machines available at some ACM Conference
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 4 Oct 85 10:12:48 PDT
Date: Fri 4 Oct 85 10:12:18-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Symbolics Machines available at some ACM Conference
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12148465172.14.ACUFF@SUMEX-AIM.ARPA>
There is supposed to be some ACM conference 13-16 of this month in
Denver, about which I know nothing. The Symbolics folks asked me to
make it known that they would have machines there which they would be
willing to let us use for demos if anyone would like to do so. Please
let me know if you are interested, and I'll put you in touch with the
correct entities.
-- Rich
-------
∂04-Oct-85 1214 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA Next week's PLANLUNCH --- WEDNESDAY (not monday) OCT.9
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Oct 85 12:14:36 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Fri 4 Oct 85 12:09:30-PDT
Date: Fri 4 Oct 85 12:09:03-PDT
From: LANSKY@SRI-AI.ARPA
Subject: Next week's PLANLUNCH --- WEDNESDAY (not monday) OCT.9
To: planlunch.dis: ;
A quick note to planlunch attendees, and particularly FOLKS@CSLI:
Because of several complaints about duplicated messages, I have decided
to stop sending planlunch announcements to FOLKS@CSLI. Instead, I will
be building my own local list of CSLI people who want to receive planlunch
announcements. SO, if you receive your planlunch announcements via
FOLKS@CSLI and want to continue to do so, please send me your net address
and I will add it to this list.
Also, two more announcements:
1) If you would like to give a planlunch talk, let me know.
2) Note the date change to WEDNESDAY for Lucy Suchman's talk (below).
Thanks,
Amy Lansky
-----------------------------------------------------------------------
WHAT IS A PLAN?
Lucy Suchman
Intelligent Systems Lab, Xerox PARC
11:00 AM, WEDNESDAY, October 9 (NOTICE DATE CHANGE)
SRI International, Building E, Room EJ228 (new conference room)
Researchers in AI have equivocated between using the term "plan" to
refer to efficient representations of action, and to the actual data and
control structures that produce behavior. But while these two uses of
the term have been conflated, they have significantly different
methodological implications. On the first use, the study of plans, as
internal representations of actions and situations, is an important
companion to the study of situated actions, but essentially derivative.
On the second use, plans as the actual mechanisms that produce behavior
are foundational to a theory of situated actions.
In this talk I will argue in support of the first use of "plans," to
refer simply to efficient representations of actions. Situated actions,
on this view, are the phenomena to be modelled, whereas the function of
plans in the generation of situated actions is taken to be an open
question. The interesting problem for a theory of situated action is to
find the mechanisms that bring efficient representations and particular
environments into productive interaction. The assumption in classical
planning research has been that this process consists in filling in the
details of the plan to some operational level. In contrast with this
assumption, I will present evidence in support of the view that situated
action turns on local interactions between the actor and contingencies
of his or her environment that, while they are made accountable to a
plan, remain essentially outside of the plan's scope.
-------
∂04-Oct-85 1358 JAMIE@SU-CSLI.ARPA graduate student offices
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Oct 85 13:58:13 PDT
Date: Fri 4 Oct 85 13:54:08-PDT
From: Jamie Marks <JAMIE@SU-CSLI.ARPA>
Subject: graduate student offices
To: folks@SU-CSLI.ARPA
We are trying to make more effective and equitable use of our space
this year, and are consequently doing some remodeling and
rearrangement of offices. Part of the purpose is to provide more
study space for graduate students than we've been able to in the past.
We've planned an open door policy for a set of offices in the trailers
(E-1, E-2, and E-3) which provide semi-private desks for 7 students
and open onto a common room which provides 7 additional workstations.
Any unoccupied desk or workstation will be available to any graduate
student granted office privileges at CSLI. We'll also provide lockers
in the common room for storage of private papers and belongings.
Please contact Jamie Marks (Jamie@CSLI) if you're interested in using
graduate student space.
-------
∂04-Oct-85 1508 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 85 15:08:22 PDT
Date: Fri 4 Oct 85 15:03:29-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12148518182.22.LIBRARY@SU-SCORE.ARPA>
Programming Expert Systems In OPS5; An Introduction To Rule-Based Programming.
by Lee Brownston, Robert Farrell, Elaine Kant, and Nancy Martin.
QA76.9.E96P76 1985.
Ada In Use. Proceedings of the Ada International Conference Paris 1985.
ed. by John Barnes, Gerald Fisher Jr. QA76.73.A16A25 1985
Algorithmic Graph Theory. by Alan Gibbs. Cambridge University Press.
QA166.G53 1985
Editing In A UNIX Environment: The vi/ex Editor. by Mohamed el Lozy.
QA76.6.L69 1985.
Handbook Of Systems Analysis: Overview Of Uses, Procedures, Applications
and Practice. by Hugh Miser and Edward Quade. T57.6.H365 1985
H. Llull
-------
∂04-Oct-85 1554 NEUMANN@SRI-CSLA.ARPA RISKS-1.18
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 4 Oct 85 15:54:37 PDT
Date: Fri 4 Oct 85 14:07:29-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
Subject: RISKS-1.18
Sender: NEUMANN@SRI-CSLA.ARPA
To: RISKS-LIST@SRI-CSLA.ARPA
RISKS-LIST: RISKS-FORUM Digest Friday, 4 Oct 1985 Volume 1 : Issue 18
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Lack of a backup computer closes stock exchange (Marty Moore)
DPMA survey on computer crime offenses (J.A.N. Lee)
Ethics vs. morality (Marty Cohen)
The Mythical Man-Month of Risk (Stavros Macrakis)
Risk Assessment by real people (Mike McLaughlin)
CRTs again, solution to one eye-problem (Mike McLaughlin)
Failure of Mexican Networks (Dave Flory)
Technical Reports Lists (Laurence Leff)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions should
be relevant to the topic, technically sound, objective, in good taste, and
coherent. Others will be rejected. Diversity of viewpoints is welcome.
Please try to avoid repetition of earlier discussions.
[Note: Despite SRI-CSL having had a nasty disk controller wipe-out [Sun-Mon]
which prevented this issue from coming out on Monday, and despite my being
East, here is RISKS-1.18.]
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Mon, 30 Sep 85 11:44:49 CDT
From: mooremj@EGLIN-VAX
Subject: Lack of a backup computer closes stock exchange
To: risks@sri-csl.arpa
When Hurricane Gloria was approaching the New York area, the New York and
American Stock Exchanges did not open. The Midwest Exchange, located in
Chicago, opened on schedule; unfortunately, it had to close 40 minutes later,
when its nationwide computer system failed. Where is the central computer
of that system located? New York, of course. The Director of the Exchange
was quoted as saying, "Well, this has got to change."
------------------------------
Date: Wed, 2 Oct 85 15:39 EST
From: Jan Lee <janlee%vpi.csnet@CSNET-RELAY.ARPA>
To: RISKS@sri-csl.arpa
Subject: DPMA survey on computer crime offenses
Peter ... here are the proper figures on Computer Crime Offenses as reported
by the DPMA from a survey taken by COMP-U-FAX (TM) and reported 1985 May 27:
(It doesn't say how many people were surveyed -- just that DPMA is an
organization of 50,000 members.)
21% reported one or more abuses in past 3 years in their workplace. 2% of
these offenses were committed by outsiders (so much for the Hacker myth!!).
The reasons for the abuses were:
27% ignorance of proper professional conduct
26% playfulness
25% personal gain
22% maliciousness
Only 45% of respondents worked for a company who had a full-time
or part-time data security person.
Only 2.2% of abuses were reported publicly (does that mean
reported to the news media or the legal authorities?).
The surveyor was Detmar Straub, Grad. School of Business Admin.,
Indiana University.
(In a note I got from Donn Parker, Donn seems to cast some aspersions
on the validity of this survey, but I haven't had chance to do anything
other than read the press release myself.)
JAN
------------------------------
Date: Fri, 27 Sep 85 13:18:47 PDT
From: Marty Cohen <mcohen%NRTC@USC-ECL.ARPA>
To: risks@SRI-CSL.ARPA
Subject: Ethics vs. morality
"Morals: Society's code for individual survival"
"Ethics: An individual's code for society's survival"
From Theodore Sturgeon, "More Than Human" ("Baby is Three" is one
part of the book), page 177 of the Ballentine books paperback.
------------------------------
Date: Thu, 3 Oct 85 19:14:56 EDT
From: macrakis@harvard.ARPA (Stavros Macrakis)
To: risks@sri-csl
Subject: The Mythical Man-Month of Risk
In reference to the discussion on the Wilson article:
> ... formula that measures risks [as] ... seconds of life lost ...
In discussing risks, whether from computer systems or other causes, it
would surely be desirable to have some reasonable guidelines.
Wilson's basic point was that we should be able to calculate costs and
benefits; a point with which I am in fundamental agreement. However,
this calculation has many difficulties. In this note, I should like
to sketch (in a somewhat disorganized way) some of these difficulties.
It is often useful to reduce complicated facts to simple unidimensional
measures for comparison. But such reduction loses a great deal of
information in general; and also ignores variation in personal utility
functions. For that matter, statistical measures should differentiate
between associations and causation.
Among the figures cited, there were several misleading measures along
these lines.
For instance, although perhaps cigarette smokers ought to allocate 12
minutes of their lives per cigarette, a lung cancer death is typically far
harder than an automobile accident death. On the other hand, car accidents
subtract years by killing fewer, younger, people; cancer by killing more,
but older, people. How to compare 5 x (lifespan 25-70) with 25 x (lifespan
63-70)? Is each 175 man-years? I have no answer, although I have certain
intuitions--in particular, `losing' the 69 man-years 1-70 seems far less
tragic than losing the 69 man-years 3 x (47-70) (`struck down in the prime
of life'): but the Wilson extract did explicitly talk only of 25+-year-olds.
Economics has various answers: discounted productivity contribution; market
value attached to hazardous jobs; .... None is satisfactory, but all are
useful for separating grossly different risks.
As for correlations, why is it that living in New York is hazardous?
Perhaps it is the pollution. But if it is the poverty or the street crime,
then poverty or bad neighborhoods (regardless of city) probably relate far
better statistically and surely causally than does residence. New York just
has many poor people and bad neighborhoods. A statistical analysis that
excludes such correlated hazards is surely non-trivial.
`Post hoc ergo propter hoc' seems especially implicated in the case of
unmarried males. There are likely advantages to being married, but
perhaps inability to find or keep a wife indicates other problems.
Then there is the presumption of linear additivity. Even the risks which
are not strongly correlated may combine: consider asbestosis and smoking.
Of course, in other cases the unidimensional metrics may be far more useful.
In the case of the costs of unreliable funds transfer, the cost to the bank
can be calculated quite precisely. In cases where these errors affect
customers, it may also be reasonable to estimate that damage (e.g., you may
lose $100 of annual profits per error of type X if a retail customer takes
his business elsewhere). If you're a materials supplier to a just-in-time
manufacturer, the monetary consequences may be far more serious: still, a
monetary measure may be meaningful.
In conclusion, it seems to me useful to develop a range of measures of cost
and benefit, and not try to reduce them to single numbers. If one wishes to
be ultra-cautious, one will then weigh the minimum expected benefit against
the maximum expected cost. If one is a `rational' gambler, perhaps the
average benefit against average cost. If one is an optimist or a gambler,
perhaps the maximum benefit against the minimum cost. I believe Howard
Raiffa (among others) discusses such issues (although I'm afraid I can't
provide a reference).
Risk-free systems are unlikely. We need good ways of evaluating risks
and benefits.
-s
------------------------------
Date: Sat, 28 Sep 85 16:05:48 edt
From: mikemcl@nrl-csr (Mike McLaughlin)
To: RISKS@SRI-CSLA.ARPA
Subject: Risk Assessment by real people
Ellen Goodman's column in The Washington Post, Saturday, 28 Sep 85, (c) 1985,
The Boston Globe Newspaper Company, is worth reading. Title is: "AIDS: The
Risks We'll Take." No, it doesn't mention computers. It really isn't much
about AIDS, either.
What it is about is people, and how risks are assessed by real people - not
by computers, or calculators, but by the folks that would die of boredom
reading this forum... or might die of something else if *we* do not
understand how *they* evaluate risks.
"In California, members of a family cut back on sugar in the decaffeinated
coffee they drink in their house - on the San Andreas fault."
"Another friend drinks only bottled water these days, eats only meat un-
touched by steroids and spends weekends hang-gliding."
"The AIDS story... is a tale about experts and the public, about the gap
between our skepticism and our longing for certainty."
Ms. Goodman also quotes an article in October's Science '85: "We may be much
more willing to accept higher risks in activities over which we have control,
such as smoking, drinking, driving or skiing, than things over which we have
little control, such as industrial pollution, food additives and commercial
airlines."
Her summation is very relevant to *us*, who read and write about SDI, the use
and non-use of computers, and so on: "This is, after all, a country that bans
saccharin and builds nuclear bombs. We argue and will go on arguing about
risk in two different languages: numbers and emotions, odds and anxieties."
If *we* cannot make ourselves understood by *them* when we discuss what
matters for the survival of *all of us*, then this forum is just a
modern form of omphaloskepsis.
- Mike
------------------------------
Date: Sat, 28 Sep 85 16:25:57 edt
From: mikemcl@nrl-csr (Mike McLaughlin)
To: RISKS@SRI-CSLA.ARPA
Subject: CRTs again, solution to one eye-problem
CRTs can cause eye strain in users who wear glasses. Distance lenses won't
focus at closer than arm's length. Reading lenses focus too close. Bifocals
require you to hold your head in one of two specific positions... neither of
which works. What to do?
I already done it. Several years ago. So much a part of my computerized
life that I didn't think of it while reading/writing via computer about CRT
usage. Got "intermediate lenses" - an Rx for glasses optimized for my CRT/
VDT viewing habits. Got comfy in front of the tube & keyboard, had a friend
measure distance from bridge of nose to CRT screen. Averaged several tries.
Gave the distance to my opthamologist - he turned out an Rx in short order.
Bought frame & lenses. Expensive. Use them *only* at office computer - don't
take them home (don't have a computer at home). Declared them as a non-
reimbursed business expense. IRS content, helped reduce cost.
Did NOT get tri-focals, because:
1. They force you into an even more rigid head position - and I believe
that rigid posture is a major cause of computer-fatigue.
2. They confused the IRS issue, which was quite clear with intermediate-
only glasses.
3. I'm not old enough to wear TRI-focals, for heaven's sake!
Suggestion:
Employers requiring use of CRT should consider paying for intermediates;
should resist paying for trifocals (or even the incremental cost of tri- over
bi-focals).
An acceptable alternative might be bifocals, distance/intermediate or inter-
mediate/reading, depending upon the user's eye condition and job content.
- Mike
------------------------------
Date: Wed 2 Oct 85 13:43:03-EDT
From: Shadow <Z.HXWY-FLORY-DAVID%CRNL20A.BITNET@UCB-VAX.Berkeley.EDU>
Subject: Failure of Mexican Networks
To: Risks@sri-csl.arpa
This doesn't refer to computer networks, but it is similar.
According to Fred Goldstein on Telecom Digest (Telecom-Request@MIT-MC.ARPA),
phone service from most of the world to Mexico City was destroyed by the
collapse of the building containing the switches, frames, etc. for Mexico
City's international gateway switch.
Sites which are major network nodes collapsing due to earthquake/etc could
result in a similar effect.
David Flory
ARPANET ---> flory@CORNELL-GVAX.ARPA or shadow@RU-AIM.ARPA
BITNET ----> z.hxwy-f@CRNL20A.BITNET
[Good engineering tends to avoid sensitivity to single-point failures
and to avoid singly connected nodes. Designing for massive failures
and disasters is of course much more difficult. PGN]
------------------------------
Date: Fri, 27 Sep 85 13:38:21 cdt
From: Laurence Leff <leff%smu.csnet@CSNET-RELAY.ARPA>
Subject: Technical Reports Lists
To: [... all sorts of lists...]
[Here is what could be a useful service if suitable indexing occurs. I
have stripped Laurence's message down. SEND to him for the original.
This is of course more general in scope than just RISKS, but seemed
worth including. -- in case you missed it elsewhere. Respond to him,
not me. PGN]
I have volunteered to organize an electronic mechanism for the distribution
of technical report lists from Universities and R&D labs. Some (and
hopefully all) of the people producing technical reports would send a copy
of the list to me. I would then send these to a moderated group on USENET
as well as a mailing list for those sites on the INTERNET who do not get
news (ARPANET, CSNET, etc.).
I need two things from you:
1) if your organization prepares technical reports and sends them
out to interested parties (perhaps for a fee), please arrange
to have electronically readable copy of your lists sent
to trlist%smu@csnet-relay.
2) if people at your organization would like to receive lists
of tech reports produced by universities and R&D labs, please
provide me an electronic address to send them to (if you are not
on USENET). Send such administrative mail to trlist-request%smu@
csnet-relay.
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂05-Oct-85 1030 JF@SU-SUSHI.ARPA Abstracts and other Information about 10/11/85 BATS
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 5 Oct 85 10:30:20 PDT
Date: Sat 5 Oct 85 10:27:29-PDT
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: Abstracts and other Information about 10/11/85 BATS
To: aflb.su@SU-SUSHI.ARPA
cc: su-bboards@SU-SUSHI.ARPA
Fellow theorists: I have received only 7 email responses about next week's
BATS. Do you want to go or not? I enclose the talk abstracts with this
message; hence there is NO EXCUSE for further delay. I need at least several
firm committments from drivers (several people said they might drive but
weren't sure).
In case you delete them, the abstracts are in
SUSHI:<JF>bats.abstracts
Wearily yours,
Joan
J. Rissanen (IBM San Jose):
Stochastic Complexity
Modifying the algorithmic notion of complexity we define the stochastic
complexity I(x) of a string of symbols x = x(1),..., x(n),
relative to a class of parametrically defined probabilistic models
to be the infinum of the code length when the data are encoded with
prefix codes, designed suitably for the given class of models. There is
an element of arbitrariness in specifying exactly the "suitable" design,
but for long strings the complexities given by
all such choices tend to a common bound, for
which an asymptotic formula can be given.
Stochastic complexity with its associated inequality has notable
consequences. First, it generalizes
Shannon's information and the associated inequality.
Secondly, stochastic complexity also sets a tight lower bound for the
prediction errors. Thirdly, the main inequality provides a way to
assess the goodness of any estimator for the parameters including their
number. Accordingly, unless too presumptuous, we submit the computation
of the stochastic complexity and the associated optimal model to be the
fundamental problem in all statistics and signal processing.
Joel Friedman (UC Berkeley):
Non-Blocking Networks
A "switching network" is a model for a telephone communication
network. A switching network is a directed acyclic graph whose set
of sources (i.e. vertices with indegree 0) is disjoint from the set
of sinks. The sources are called "callers," and the sinks are called
"receivers." At any time, a caller may request to talk to a receiver,
provided they are both idle, i.e. not engaged in another conversation.
We must then connect the caller to the receiver via a path in the graph
which is vertex disjoint from any other conversation path currently
in use. At any time the caller can request to hang up and, perhaps,
talk to a different receiver. A network that can handle any such
sequence of requests is called "non-blocking." In short, a non-blocking
network can dynamically handle all hookup and hangup requests from
callers to receivers.
Two variants of the concept "non-blocking" appear in the literature:
"strictly" non-blocking, and "wide-sense" non-blocking. When a
caller requests to talk to a receiver, there may be many paths available
to hookup the two. A strictly non-blocking network is one where
hookup requests can be handled by any available path. A wide-sense
non-blocking network is one with a strategy for choosing paths (given
the state of the network and the caller and receiver) which makes the
network non-blocking. A wide-sense network can be blocked if an
adversary chooses the connecting paths, a strictly non-blocking network
can't.
In this talk I will describe new results which, for the first time,
show that wide-sense non-blocking networks can be less expensive that
strictly non-blocking networks. In the simplest case we show that depth
2 strictly non-blocking must have n↑2 edges, while wide-sense networks
exist with n↑1.5 (log n)↑.5 edges.
Allen Van Gelder (Stanford):
Parallel Complexity of Function-Free Logic Programs
(joint work with Jeffrey D. Ullman)
We consider the parallel time complexity of logic programs
without function symbols.
We give a PRAM algorithm for computing the minimum model of a function-free
Horn logic program, and show that for programs with the
``polynomial fringe property,'' this algorithm runs in poly-log time.
As a result, the ``linear'' and ``piecewise linear'' classes of
logic programs, as well as the word problem for CFLs, are in NC.
(Using ideas of Miller and Reif that were recently presented at MSRI,
we can actually show log↑1 PRAM time and NC↑2 membership.)
Then we examine several non-linear cases in which the program has
a single recursive rule that is an ``elementary chain.''
We demonstrate a connection between such programs and context free grammars.
Among such ``elementary single rule'' programs that are non-linear,
we exhibit cases, analogous to balanced parentheses languages,
that have the ``polynomial fringe property,'' hence are in NC.
Also, we exhibit an elementary single rule program that is P-complete.
Janet Blumer (UCSC):
Minimal Automata For The Set Of All Suffixes And The Set Of All Subwords
The Directed Acyclic Word Graph (DAWG) is a directed acyclic graph that
can be viewed as the minimal DFA for the set of all suffixes of a word.
It will be proved linear in the size of the word, and an algorithm will
be described which builds the DAWG on-line in linear time. With a
different assignment of accepting states, the DAWG can be viewed as a DFA
for the set of all subwords of a word. As such, it is not minimal, but
closely related to the minimal subword automaton. This relationship
is examined, producing tighter bounds on the size of the minimal subword
automaton and indicating modifications to the DAWG construction algorithm
that allows the minimal subword automaton to be built on-line in linear
time.
-------
∂05-Oct-85 1701 @SU-CSLI.ARPA:barwise@csli-whitehead Linguistics Positions
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 5 Oct 85 17:01:23 PDT
Received: from csli-whitehead ([36.9.0.8].#Internet) by SU-CSLI.ARPA with TCP; Sat 5 Oct 85 16:56:31-PDT
Received: by csli-whitehead with TCP; Sat, 5 Oct 85 14:59:14 pdt
Date: Sat, 5 Oct 85 14:59:14 pdt
From: Jon Barwise <barwise@csli-whitehead>
Subject: Linguistics Positions
To: folks@csli
CMU is starting a new program in linguistics in the philosophy department
and is advertising two tenure track positions. This seems like a great
opportunity, since the Pittsburgh
area is so strong in CS, Phil and Logic. Ingrid has copies of the
announcemnet if you want one.
Jon
∂07-Oct-85 0032 DAVIES@SUMEX-AIM.ARPA This week's meeting
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 00:32:22 PDT
Date: Mon, 7 Oct 1985 00:33 PDT
Message-ID: <DAVIES.12149146214.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: This week's meeting
cc: Davies@SUMEX-AIM.ARPA
It has been difficult to find a technical topic for this week's
meeting. Some people were out of town last week, so they couldn't
contribute to the selection of a topic. Others will be out of town
this week, so they had little to say about the topic of a meeting they
wouldn't be attending. Nonetheless, there are some business matters
to be discussed, so there will be a meeting Wednesday at 9:30 am.
Suggestions for a technical topic are welcomed.
-- Byron
∂07-Oct-85 0632 PATASHNIK@SU-SUSHI.ARPA Next AFLB
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 06:32:23 PDT
Date: Mon 7 Oct 85 06:28:50-PDT
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: Next AFLB
To: aflb.all@SU-SUSHI.ARPA
We have no speaker for next week, October 17, yet. Please let me
know if you'd like to speak.
********************************
10-Oct-85 - Eli Shamir (Hebrew University)
New results about graph coloring
The chromatic number of a random graph with expected degree d(n) is
sharply concentrated around b*d(n)/logd(n). There are provably good
heuristics to unravel the coloring of a dense graph with an unusually
small number of color classes.
***** Time and place: October 10, 12:30 pm in MJ352 (Bldg. 460) ******
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352 (Bldg.
460).
If you have a topic you would like to talk about in the AFLB seminar
please let me know. (Electronic mail: patashnik@su-sushi.arpa, phone:
(415) 497-1787). Contributions are wanted and welcome. Not all time
slots for this academic year have been filled.
For more information about future and past AFLB meetings and topics
are in the file [SUSHI]<patashnik.aflb>aflb.bboard .
- Oren Patashnik
-------
∂07-Oct-85 0815 EMMA@SU-CSLI.ARPA Logic Lunch
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 08:15:04 PDT
Mail-From: BARWISE created at 6-Oct-85 14:45:14
Date: Sun 6 Oct 85 14:45:14-PDT
From: Jon Barwise <BARWISE@SU-CSLI.ARPA>
Subject: Logic Lunch
To: AFA@SU-CSLI.ARPA, clt@SU-AI.ARPA, paolo@SU-CSLI.ARPA
cc: SF@SU-CSLI.ARPA, emma@SU-CSLI.ARPA
ReSent-Date: Mon 7 Oct 85 08:13:51-PDT
ReSent-From: Emma Pease <Emma@SU-CSLI.ARPA>
ReSent-To: "@ps:<csli-lists>finterest.dis"@SU-CSLI.ARPA
Just in case any of you missed the announcement in the Newsletter, we
are starting a Logic Lunch tomorrow (Monday). Ordinarily we will meet
in the philosophy lounge, but tomorrow it will be in the philosophy
seminar room. Tell all your friends.
-------
∂07-Oct-85 0819 HAUNGA@SUMEX-AIM.ARPA Title & abstract for the SIGLUNCH, Friday 11th.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 08:18:52 PDT
Date: Mon 7 Oct 85 08:16:34-PDT
From: Ana Haunga <HAUNGA@SUMEX-AIM.ARPA>
Subject: Title & abstract for the SIGLUNCH, Friday 11th.
To: SIGLUNCH@SUMEX-AIM.ARPA
cc: Haunga@SUMEX-AIM.ARPA
Message-ID: <12149230536.25.HAUNGA@SUMEX-AIM.ARPA>
The SIGLUNCH will be held at the Chemistry Gazebo at
12:05 p.m. - 1:00 p.m.
-------------
TWO EFFORTS TOWARD SOFTWARE ICAI
BY
Lewis Johnson
Software systems are a rich domain for intelligent computer-
based training. In this talk I will discuss two efforts which
relate to software ICAI. The first is PROUST, a system which
finds bugs in programs written by novice Pascal programmers.
PROUST analyzes bugs by identifying each programmer's intentions, and
their reflection in their programs. This results in a detailed
understanding of the bugs and the misconceptions that probably
caused them, information which is indispensable to an intelligent
tutoring system for programming. Results of classroom tests of
PROUST will be presented.
The second effort is the development of a high-level software
design language, called ODETTE. Software is difficult to understand
and maintain because programming languages describe program behavior, and
do note relate it to the user's behavior, nor to the designer's and
user's goals. ODETTE enables designers to make all of these
explicit in the design. Our long-term goal is to build tools to
support enhancement of ODETTE designs, and to generate intelligent
interfaces with built-in explanation and training facilities.
------ relate it to the user's behavior, nor to the designer's and
-------
∂07-Oct-85 0921 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 09:21:06 PDT
Date: Mon 7 Oct 85 09:09:24-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch Series
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA, bureaucrats@SU-SCORE.ARPA
Message-ID: <12149240155.17.RICHARDSON@SU-SCORE.ARPA>
The title and speaker for tomorrow's lunch in MJH 146 at 12:15 is:
Dean Gibbons on "CSD and the School of Engineering".
Anne
-------
∂07-Oct-85 0949 ullman@su-aimvax.arpa meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 09:48:49 PDT
Received: by su-aimvax.arpa with Sendmail; Mon, 7 Oct 85 09:46:47 pdt
Date: Mon, 7 Oct 85 09:46:47 pdt
From: Jeff Ullman <ullman@diablo>
Subject: meeting
To: nail@diablo
I'm going to be away this Wednesday, so I
suggest we cancel the meeting unless
anyone volunteers to lead a discussion.
In general, we need volunteers to present
their own ideas or discuss any of a number of
papers that I have received recently and look interesting.
For example:
Termination of rewriting (Dershowitz)
Parallel Algs. for term matching (Dwork, Kanellakis, and Stockmeyer)
Bounded Recursion in deductive DB's (Ioannidis)
Ordering conjunctive queries (Smith and Genesereth)
Finding all solutions to a problem (Smith and Genesereth)
Controlling recursive inference (Smith, Genesereth, and Ginsberg)
Volunteers??
∂07-Oct-85 1026 ullman@su-aimvax.arpa paper just received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 10:26:27 PDT
Received: by su-aimvax.arpa with Sendmail; Mon, 7 Oct 85 10:22:27 pdt
Date: Mon, 7 Oct 85 10:22:27 pdt
From: Jeff Ullman <ullman@diablo>
Subject: paper just received
To: nail@diablo
WOuldn't you know it: 2 minutes after I sent out my list
of papers, the following arrived:
Recursive axioms in deductive databases: the querry-subquery
approach, by Laurent Vieille
It seems to be another algorithm in the Lozinskii/McKay-Shapiro
class, in fact, probably equivalent to Van Gelder's algorithm,
in that he seems to distinguish "masks," which are patterns
in which constants appear.
∂07-Oct-85 1444 WASHINGTON@SUMEX-AIM.ARPA Siglunch location
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 14:44:37 PDT
Date: Mon 7 Oct 85 14:41:53-PDT
From: Rich Washington <washington@SUMEX-AIM.ARPA>
Subject: Siglunch location
To: sjg@SU-AI.ARPA, siglunch@SUMEX-AIM.ARPA
Message-ID: <12149300682.68.WASHINGTON@SUMEX-AIM.ARPA>
Judging from attendance the past two weeks, the chemistry gazebo
is painfully inadequate for the Siglunches. I agree that it is
a much more desirable location than Braun Auditorium, but I think
it's only facing reality to admit that we are in a popular field
of research/study. We should be welcoming people in to see what
we're working on, and staying in the present cramped conditions
can only have the opposite effect.
Rich
-------
∂07-Oct-85 1841 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar on Logic and the Foundations of Mathematics
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 7 Oct 85 18:35:02 PDT
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 7 Oct 85 18:32:27-PDT
Date: 07 Oct 85 1822 PDT
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: Seminar on Logic and the Foundations of Mathematics
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
Speaker: Marian Pour-El, University of Minnesota, visiting MSRI
Title: Computability of standard processes in analysis and physics.
Time: Monday, Oct.14, Noon to 1:15
Place: Ventura Hall Seminar Room
S. Feferman
Note the change of time and place!!
The regular meeting time of this seminar has been changed to Friday noon.
We will meet alternate weeks beginning Friday October 25th.
∂07-Oct-85 1850 CLT Seminar on COMMON SENSE AND NON-MONOTONIC REASONING
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
A series of seminars on
COMMON SENSE AND NON-MONOTONIC REASONING
will explore the problem of formalizing commonsense knowledge and reasoning,
with the emphasis on their non-monotonic aspects.
It is important to be able to formalize reasoning about physical objects
and mental attitudes, about events and actions on the basis of predicate logic,
as it can be done with reasoning about numbers, figures, sets and probabilities.
Such formalizations may lead to the creation of AI systems which can use logic
to operate with general facts, which can deduce consequences from what they know
and what they are told and determine in this way what actions should be taken.
Attempts to formalize commonsense knowledge have been so far only
partially successful. One major difficulty is that commonsense reasoning often
appears to be non-monotonic, in the sense that getting additional information
may force us to retract some of the conclusions made before. This is in sharp
contrast to what happens in mathematics, where adding new axioms to a theory
can only make the set of theorems bigger.
Circumscription, a transformation of logical formulas proposed by John
McCarthy, makes it possible to formalize non-monotonic reasoning in classical
predicate logic. A circumscriptive theory involves, in addition to an axiom set,
the description of a circumscription to be applied to the axioms. Our goal is
to investigate how commonsense knowledge can be represented in the form of
circumscriptive theories.
John McCarthy will begin the seminar by discussing some of the problems
that have arisen in using abnormality to formalize common sense knowledge about
the effects of actions using circumscription. His paper Applications of
Circumscription to Formalizing Commmon Sense Knowledge is available from Rutie
Adler 358MJH. This paper was given in the Non-monotonic Workshop, and the
present version, which is to be published in Artificial Intelligence, is not
greatly different. The problems in question relate to trying to use the formalism
of that paper.
The seminar will replace the circumscription seminar we had last year.
If you were on the mailing list for that seminar then you will be automatically
included in the new mailing list. If you would like to be added to the mailing
list (or removed from it) send a message to Vladimir Lifschitz (VAL@SAIL).
The first meeting is in 252MJH on Wednesday, October 30, at 2pm.
∂08-Oct-85 0011 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu ICDT 86 - Call For Papers
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 00:11:27 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Tue 8 Oct 85 00:04:12-PDT
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Mon 7 Oct 85 23:10:54-PDT
Received: by rsch.wisc.edu; Tue, 8 Oct 85 00:48:27 cdt
Received: from crys.wisc.edu by rsch.wisc.edu; Mon, 7 Oct 85 20:05:06 cdt
Received: from sri-iu.arpa by crys.wisc.edu; Mon, 7 Oct 85 20:04:48 cdt
Date: Mon 7 Oct 85 18:06:40-PDT
From: Moshe Vardi <VARDI@SRI-IU.ARPA>
Subject: ICDT 86 - Call For Papers
To: theory@WISC-CRYS
Message-Id: <VAX-MM(162)+TOPSLIB(114)+PONY(0) 7-Oct-85 18:06:40.SRI-IU.ARPA>
Sender: udi@rsch.wisc.edu
Resent-From: udi@rsch.wisc.edu (Udi Manber)
Resent-To: theory:;
Call For Papers
ICDT 86
International Conference on Database Theory
Rome, September 8-10, 1986
The conference is intended to provide a European forum
for the international research community on theoretical
issues related to database systems. It will be held in
downtown Rome, in the main building of CNR (the Italian
Research Council), sponsored by the European Association for
Theoretical Computer Science (EATCS) and jointly organized
by Consorzio per la Ricerca e la Applicazioni in Informatica
(CRAI), Dipartmento di Informatica e Sistematica - Univer-
sita di Roma "La Sapienza", and Instituto di Analisi dei
Sistemi ed Informatica del Consiglio Nazionale delle
Ricerche (IASI-CNR).
←λT←λo←λp←λi←λc←λs
Major themes to be covered are (this is not meant to be
an exclusive list): relational theory, logic and databases,
conceptual models, knowledge representation and databases,
deductive databases, theory of distributed databases and
concurrency control, analysis and design of data structures,
database interfaces, and query processing.
←λP←λa←λp←λe←λr←λs
Authors should submit six copies of a full draft before
March 15, 1986, to the Chairman of the Program Committee:
Giorgio Ausiello
Dipartmento di Informatica e Sistematica
Universita di Roma "La Sapienza"
Via Eudossina, 18
00184 Roma, Italy
Authors will be notified of the program committee deci-
sion on their papers by June 1, 1986. Final versions will
be due July 15, 1986. Proceedings will be available at the
Conference in the form of preprints, and will be published
in a book form a few months later.
←λP←λr←λo←λg←λr←λa←λm ←λC←λo←λm←λm←λi←λt←λt←λe←λe
S. Abiteboul (France); G. Ausiello (Italy); F. Ban-
cilhon, (France, USA); A. D'Atri (Italy); W. Lipski (Poland,
USA); M. Moscarini (Italy), J. Mylopoulos (Canada); J.M.
Nicolas (France, FRG); J. Nievergelt (Switzerland); C.H.
Papadimitriou (Greece, USA); J. Paredaends (Belgium); D.
Sacca (Italy); N. Spyratos (France); J.D. Ullman (USA); M.Y.
Vardi (USA).
←λO←λr←λg←λa←λn←λi←λz←λi←λn←λg ←λC←λo←λm←λm←λi←λt←λt←λe←λe
P. Atzeni (IASI-CNR); A. D'Atri (Universita di Roma);
M. Moscarini (IASI-CNR); D. Sacca (CRAI).
←λS←λt←λu←λd←λe←λn←λt ←λA←λw←λa←λr←λd
A $500 prize for the best paper authored solely by stu-
dents will be awarded to commemorate our friend and col-
league Witold Lipski (1949-1985), who departed after agree-
ing to serve on the program committee. Those who wish to be
considered for the prize are invited to formally state their
student status in a letter accompanying the paper.
←λF←λu←λr←λt←λh←λe←λr ←λI←λn←λf←λo←λr←λm←λa←λt←λi←λo←λn
Paolo Atzeni
IASI-CNR
Viale Manzoni, 30
00185 Roma, Italy
Tel. (39 6) 77.00.31
-------
∂08-Oct-85 0111 NEUMANN@SRI-CSL.ARPA RISKS-1.19
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 01:10:56 PDT
Date: Mon 7 Oct 85 23:58:57-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSL.ARPA>
Subject: RISKS-1.19
Sender: NEUMANN@SRI-CSL.ARPA
To: RISKS-LIST@SRI-CSL.ARPA
RISKS-LIST: RISKS-FORUM Digest Monday, 7 Oct 1985 Volume 1 : Issue 19
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Emanations and interference in the civil sector (Peter Neumann,Jerry Saltzer)
Administrivia -- Escaped Mail and Delays (Mark S. Day)
Computer databases (Andy Mondore)
Re: Friendly test teams (John Mashey)
Re: CRTs again, solution to one eye-problem (Brint Cooper)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions
should be relevant to the topic, technically sound, objective, in good
taste, and coherent. Others will be rejected. Diversity of viewpoints is
welcome. Please try to avoid repetition of earlier discussions.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Sun 6 Oct 85 15:16:38-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Emanations and interference in the civil sector
To: RISKS@SRI-CSLA.ARPA
I have had several queries about risks in the civil sector concerning
electronic emanations from and electronic interference upon computer systems
and networks -- and of course also about what can be done to protect oneself
or one's company. For example, Martin Lee Schoffstall <schoff%rpi.csnet
@csnet-relay.arpa> wondered along these lines:
If you were building a hospital from scratch, would you consider
shielding for your computer room, how many electron volts would
you shield for, etc.?
In general I would like some feedback for us civilians...
This subject is generally a technically intricate one, but some guidance is
clearly necessary for the civil sector. Thus, it seems worthwhile to note
several examples that represent varying degrees of risk to the public.
(Since microprocessor-controlled systems are becoming ubiquitous, related
problems are likely to recur in other guises. But let us not quibble about
whether THESE examples are sufficiently computer-related.) The first three
examples involve interference; all but the third involve emanations.
Transmit: Microwave oven emanations
Receive: "Externally reprogrammable" heart pacemaker -- interference;
pacemaker reset by microwaves to 214 beats per minute
Result: Dead patient (See Software Engineering Notes vol 5 no 1 Jan 1980.)
Transmit: Anti-theft device emanations
Receive: Heart pacemaker -- interference
Result: Patient OK (See Software Engineering Notes vol 10 no 2 Apr 1985,
but I have seen nothing more recent.)
Transmit: Active radar jammer (in speeder's auto)
Receive: Police radar receiver
Result: In one currently popular device, the jammer simulates a fault
mode common in the design of many police radars systems.
(... a program bug or an electronic interface problem?)
Transmit: Police radar transmitters
Receive: Radar signals (received by transmitter, and by targetted autos)
Result: With passive detector, driver can avoid arrest.
Transmit: Microwave telephone transmitters (telephone company)
Receive: Capture telephone conversations and data (observer)
Result: Compromise
Transmit: Radiating CRT or keyboard (unsuspecting computer user)
Receive: Recreate screen image or typed input remotely (observer)
Result: Compromise (Unclassified technology for doing this has
recently been described in a European defense magazine.)
[The RISKS Forum has discussed CRT radiation with respect
to possible health hazards, so I won't list that again.]
The radar detector and jammer are marginally computer-relevant, and are
included here primarily because they are illustrative of deeper problems --
fielding a computer system and its surrounding environment that can be
defeated in some relatively simple way. [By the way, this forum does not
endorse or promote illegal activities -- we merely need to point out their
existence.] (I have not included in this list the garage-door openings and
closings triggered by the orbiting Sputnik, which happened to be on the
right frequency.)
Emanations and interference may be accidental or intentional. Passive
techniques for detection may require some computing as in the case of
unscrambling multiplexed communications. Active techniques (e.g., for
intentional jamming) are at this point much less common, but are likely to
present greater risks in the future. There are all sorts of more or less
relevant laws, but they are probably neither complete enough nor concise
enough. There are also all sorts of commonly available devices for those
who want to break the laws.
This note is intended to help raise the general level of awareness. With
pretenses of corporate secrecy being what they are, it would be nice to be
able to assess the real risks. In the past, many of these risks have seemed
obscure, but that seems to be changing. Suggestions on how to avoid those
risks are welcome. (There are of course also nonelectronic forms of
emanations; various penetrations are reported to have begun with information
-- including passwords -- gained by reading the contents of dumpsters.)
The answers to Marty Schoffstall's hospital query, and other such questions,
depend on the perceived risks against which you think you are defending.
For Marty's example, are you trying to provide survival of the hospital
computers and communications against nuclear attack? or something less
serious such as intentional jamming or accidental interference? Might you
be worried about compromises of privacy resulting from wire-taps and
microwave pickups of computer information? Each threat suggests a variety
of possible measures or countermeasures. PGN
------------------------------
Date: Fri, 4 Oct 85 18:02 EDT
From: Saltzer@MIT-MULTICS.ARPA <Jerry Saltzer>
Subject: Emanations and interference in the civil sector
To: Neumann@SRI-CSL [in response to a query]
Concern for Electromagnetic Compatibility is indeed beginning to become an
important design consideration in consumer products. These days, TV sets
are beginning to clean up their act, but the average FM tuner just can't
cope with being in a substantial RF field. As consumers start to collect a
walkman, TV, cable converter, FM tuner, stereo amplifier, VCR, CD player,
cordless phone, remote control light switches, microwave oven, and
garage-door opener under one roof, more and more people are becoming aware
of the problems, and discovering that some manufacturers didn't put the
right effort in.
------------------------------
Date: Thu 3 Oct 85 20:07:38-EDT
From: Mark S. Day <MDAY@MIT-XX.ARPA>
Subject: Administrivia -- Escaped Mail and Delays
[ Excerpted-From: Soft-Eng Digest Sat, 5 Nov 85 Volume 1 : Issue 34 ]
XX was a victim of Hurricane Gloria; it had multiple head crashes when it
was restarted after the storm. The heroic efforts of the staff here brought
the machine back to life after a marathon of restoring files, which
unfortunately left the alias for this list in a strange state. Instead of
going into my mailbox, everything sent to "Soft-Eng" was immediately
redistributed. Fortunately, only one message got out between the time XX
came up and the time I noticed the problem. Anyway, sorry for the
difficulties. No doubt this will now appear in the RISKS mailing list as an
example of an unreliable computer system...
[SURE. WHY NOT??!! Recovery and reinitialization are a vital part of
keeping a system running properly. How many times have you put in a
patch or fix only to find that it somehow disappeared, e.g., not
surviving a crash or not getting propagated back into the source code?
But in this case you got left in an unsafe state! PGN]
------------------------------
Date: Sat, 28 Sep 85 16:20:46 EDT
From: Andy←Mondore%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
To: RISKS@sri-csl.arpa
Subject: Computer databases
One topic I have not seen discussed here is that of computer databases. I
am Systems Coordinator for the Registrar's Office here so I am in charge of
a fairly large database containing (obviously) student grade and course
information as well as addresses, demographic information, etc. I'd like to
see a discussion of the risks of having incorrect information in a database,
information being seen or accessed by the unauthorized individuals, etc.
Thanks.
[Ah, yes. This is a wonderful topic. The state of the art of database
management systems that can handle sophisticated privacy/compromise and
data integrity problems is rather abysmal. However, the risks of
people gleaning information by drawing inferences from a database are
considerable. For starters, see Dorothy Denning's book, Cryptography
and Data Security, Addison Wesley, 1982. As to risks, Software
Engineering Notes has had a bunch of stories on the effects of misuse
or mininterpretation of police data. The Air New Zealand catastrophe
was an example of what can happen if a change is not propagated
properly. As always, contributions are welcome. PGN]
------------------------------
Date: Sat, 28 Sep 85 22:31:18 pdt
From: mips!mash@glacier (John Mashey)
To: glacier!risks@sri-csl.ARPA
Subject: Re: Friendly test teams
It might be good to ask for pointers to published data on bug histories,
effort levels, robustness in large hardware/software systems. I suspect
these may be hard to find for SDI-like systems; I couldn't dig up any old
Safeguard info. Although not in the same class of difficulty, ATT's new #5
ESS switch is fairly complex (300+ engineers). A good reference is: H.A.
Bauer, L.M. Croxall, E.A. Davis, "System Test, First-Office Application, and
Early Field Experience", ATT Technical Journal, vol 64, No 6, Part 2
(Jul-Aug 1985), 1503-1522.
------------------------------
Date: Sun, 6 Oct 85 12:59:18 EDT
From: Brint Cooper <abc@BRL.ARPA>
To: mikemcl@NRL-CSR.ARPA
cc: RISKS@SRI-CSL.ARPA
Subject: Re: CRTs again, solution to one eye-problem
[We started out keeping one eye on this problem, but it does not
want to stay out of sight. Will this be the last message? PGN]
A cheaper but similar solution was suggested by my opthalmalogist when I
attained that stage of life wherein my arms are too short.
Since I needed a small, positive correction (about +1.0) in each eye, I
purchased, at his suggestion, "reading glasses" from the local pharmacy for
about $12.00. Since then, my eyes have worsened a little and I need about
+1.25 to +1.5 diopters for reading. But this is too strong for the terminal
(an AT&T 5620 with rather small font), so I retained the old +1.0 diopter
lenses for the terminal at work. At $12.00 each, I can afford to have a
pair at the office, a pair at home, and a pair to carry.
Note: This won't work if one has astigmatism or if one needs widely
different corrections in each eye. But ask your doc. You can buy a lot of
OTC glasses for $200.
Oh yes, it is a small nuisance to switch glasses from terminal lenses to
reading lenses, but one learns quickly to minimize the hassle.
Brint
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂08-Oct-85 0912 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 09:11:56 PDT
Date: Tue 8 Oct 85 09:09:30-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch Series
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA, bureaucrats@SU-SCORE.ARPA
Message-ID: <12149502317.16.RICHARDSON@SU-SCORE.ARPA>
Don't forget lunch today at 12:15 in MJH 146!
-------
∂08-Oct-85 0936 @SU-SCORE.ARPA:TW@SU-AI.ARPA Reminder about forum talks
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 09:36:46 PDT
Received: from SU-AI.ARPA by SU-SCORE.ARPA with TCP; Tue 8 Oct 85 09:34:09-PDT
Date: 08 Oct 85 0935 PDT
From: Terry Winograd <TW@SU-AI.ARPA>
Subject: Reminder about forum talks
To: faculty@SU-SCORE.ARPA
CC: tajnai@SU-SCORE.ARPA
This is a reminder that I have requested names of students who might speak
at this year's forum, to be sent to me by Oct 11 (this Friday). So far
only five faculty members have responded to my request. One of them
proposed four candidates and another said he had enough for a whole
session. We would like a broader representation, so please respond if you
haven't. --t
∂08-Oct-85 1043 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 10:42:31 PDT
Date: Tue 8 Oct 85 10:33:33-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch Series
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA, bureaucrats@SU-SCORE.ARPA
Message-ID: <12149517616.16.RICHARDSON@SU-SCORE.ARPA>
Unfortunately, Dean Gibbons will be unable to attend the CSD Lunch today.
Instead, Nils Nilsson will lead an informal discussion about the policies
for hiring and promoting Research Associates.
-------
∂08-Oct-85 1424 @SU-CSLI.ARPA:LANSKY@SRI-AI.ARPA PLANLUNCH mailing list
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 14:22:58 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 8 Oct 85 14:16:41-PDT
Date: Tue 8 Oct 85 14:02:13-PDT
From: LANSKY@SRI-AI.ARPA
Subject: PLANLUNCH mailing list
To: folks@SU-CSLI.ARPA
This is a reminder to those of you who:
1) want to continue getting PLANLUNCH notices
2) are NOT on sri's aic-associates list
3) have not yet sent a message to me concerning remaining on the list
to send me a notice that you WANT to remain on the mailing list.
I am constructing my own subset of of FOLKS@CSLI to send PLANLUNCH notices to.
I hope you could parse this message!,
-Amy Lansky (LANSKY@SRI-AI)
-------
∂08-Oct-85 1724 ullman@su-aimvax.arpa meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 17:24:05 PDT
Received: by su-aimvax.arpa with Sendmail; Tue, 8 Oct 85 17:20:52 pdt
Date: Tue, 8 Oct 85 17:20:52 pdt
From: Jeff Ullman <ullman@diablo>
Subject: meeting
To: nail@diablo
remember--no meeting tomorrow.
∂08-Oct-85 1756 BSCOTT@SU-SCORE.ARPA No-Smoking Policy
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 17:56:04 PDT
Date: Tue 8 Oct 85 17:50:28-PDT
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: No-Smoking Policy
To: CSD@SU-SCORE.ARPA
cc: BScott@SU-SCORE.ARPA
Message-ID: <12149597154.11.BSCOTT@SU-SCORE.ARPA>
Nils Nilsson has asked me to remind everyone about the Stanford No-Smoking
Policy.
Smoking is prohibited in indoor locations where smokers and non-smokers occupy
the same area. Such areas include:
Academic areas: classrooms, lecture halls, seminar rooms, laboratories,
libraries, computing facilities.
Conference rooms, auditoria, exhibition areas, indoor athletic facilities,
theaters, pavilions, and retail stores.
Health facilities not subject to Stanford University Hospital or Stanford
University Medical Center no-smoking regulations.
Open areas (shared spaces not fully enclosed by floor to ceiling partitions
and doors).
Other common/public areas including: stairwells, elevators, escalators,
lobbies, hallways, waiting rooms, reception areas, restrooms, and
customer service areas.
Any area in which a fire or safety hazard exists.
-------
∂08-Oct-85 1910 NEUMANN@SRI-CSL.ARPA RISKS-1.20
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 19:10:25 PDT
Date: Tue 8 Oct 85 17:45:26-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSL.ARPA>
Subject: RISKS-1.20
Sender: NEUMANN@SRI-CSL.ARPA
To: RISKS-LIST@SRI-CSL.ARPA
RISKS-LIST: RISKS-FORUM Digest Wednesday, 9 Oct 1985 Volume 1 : Issue 20
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Risks using robots in industry (Bill Keefe)
Re: Computer databases (Matt Bishop)
Registrar's databases; Database risks - census data (Hal Murray, 2 messages)
The winners of evolution... (William McKeeman)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions should
be relevant to the topic, technically sound, objective, in good taste, and
coherent. Others will be rejected. Diversity of viewpoints is welcome.
Please try to avoid repetition of earlier discussions.
Warning: Dave Poole will be at it again tonight -- risk of multiple copies!
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Tuesday, 8 Oct 1985 07:26:03-PDT
From: keefe%milrat.DEC@decwrl.ARPA (Bill Keefe)
To: risks@sri-csl.ARPA, keefe%milrat.DEC@decwrl.ARPA
Subject: Risks using robots in industry
I don't know who to credit with typing this in. I was going to summarize,
but it's too easy to take some points out of context. It brings up many
questions as to who bears the responsibility (liability?) to protect people
from such occurrences.
--------------------------------
In The Lion's Cage" [Forbes Oct. 7, 1985]
On July 21, 1984, at about 1 p.m., a worker at Diecast Corp. in Jackson, Mich.
found Harry Allen, 34, a diecast operator pinned between a factory pole and the
back of an industrial robot. But Allen's co-worker couldn't come to his aid.
Using the robot's controller, the company's director of manufacturing finally
unpinned Allen, who was alive but in cardiac arrest. He died in a hospital
five days later.
Allen had entered a restricted area, presumably to clean up scrap metal from
the floor. While there, he got in the way of the robot's work, and thus became
the first - and so far only - U.S. victim of an industrial robot-related
accident.
That's not a bad safety record, considering that 17,000 robots are now
installed in the U.S. But the bet is he won't be the last. The Japanese, who
lead the world in robot installations, also lead in robot-related fatalities:
There have been reports of at least 5, and possibly as many as 20, such deaths
in Japan.
That's only fatalities. In this country, companies are not required to report
injuries related to specific equipment, so no reliable data are available. But
in Sweden, a pioneer in the use of industrial robots, one study estimates that
there is 1 accident a year for every 45 robots. By 1990, when the number of
robots installed in American Industry could climb as high as 90,000, the
number of injuries could climb accordingly. That's because robots move quickly
and are programmed to go through a series of motions without stopping. A
worker who gets in the way can be struck, pushed aside, crushed or pinned to
a pole as Allen was.
How will industry minimize the risk to its workers? Probably with difficulty.
Robots don't easily accommodate safeguards. Whereas most machinery operates
within a fixed set of boundaries, robots have a large "striking distance" - the
reach of their mobile arms within three dimensions. In automotive assembly
plants, maintenance workers often collide with robots adjacent to the ones
they're servicing because they don't realize they are in another robot's work
area. A robot may perform one task five times and then start on a completely
different activity, and with it a different set of motions. Also, a robot can
sit idly for a time and then come to alive again, threatening injury to a
worker who mistakenly thought it was shut down.
What's being done to make robots safer? Right now, not much. "The extent of
most safety precautions are signs saying, 'Restricted Area: Keep Out,' or
maybe a guardrail," says Howard Gadberry of the Midwest Research Institute in
Kansas City, Mo. Indeed, the most common safeguards - perimeter barriers such
as guardrails and electric interlocked gates, which automatically shut down
the robot when opened - don't protect those maintenance workers and programmers
who must enter the lion's cage. Presence-sensing devices, such as
pressure-sensitive mats and light curtains, both of which automatically cut
off a robot's power, also don't seem to offer as much protection as is needed,
if only because workers are even more unpredictable in their movements than
robots. They may not step on the mat when feeding parts to a robot, or they
may not break a light curtain's beam.
That's not to say that robots can't be made safer. Researchers at the
Renssalaer Polytechnic Institute, for example, recently completed a research
prototype for several large U.S. companies of a four-sensor safety system that
continuously monitors the area around a robot. Using ultrasonic, infrared,
capacitance and microwave sensors, the RPI system is designed to stop a robot
in its tracks if a worker gets too close. Cost? Five thousand dollars
in production, according to Jack Meagher, a senior project manager at RPI.
The National Bureau of Standards has also been working with ultrasonic sensors
on robot arms similar to the system at RPI. They both have developed a
secondary, or watchdog, computer to monitor the actions of the robot and its
microprocessor. After all, if the robot's computer goes berserk, how can it
monitor itself? That's more important than you might think, 30% of robot
accidents seem to be caused by runaways, according to John Moran, director of
research at the National Institute for Occupational Safety & Health.
While such systems slowly make the transition form research to the factory
floor, industry is trying to put basic safety standards into practice.
Recently, the Robotic Industries Association proposed a set of national safety
standards for robots that could go into effect as early as next summer.
Would such standards have prevented Harry Allen's death? Maybe not. The robot
at the Diecast plant was surrounded by a safety rail with an electric
interlocked gate that automatically shut down the robot when the gate was
opened. However, there were two gaps in the rail that allowed workers to
easily bypass the safeguard; that has since been corrected by the company.
Says Allan Harvie, deputy director of the Michigan Department of Labor's
bureau of safety and regulation, "I could only presume Harry Allen thought he
could go in and do what he intended to do without having to shut the robot
down."
------------------------------
Date: 8 Oct 1985 1123-PDT (Tuesday)
From: Matt Bishop <mab@riacs.ARPA>
Organization: Research Institute for Advanced Computer Science
Address: Mail Stop 230-5, NASA Ames Research Center, Moffett Field, CA 94035
Phone: (415) 694-6363 [main office], (415) 694-6921 [my office]
To: risks@sri-csl.ARPA
Subject: Re: Computer databases
I guess I'll start the ball rolling on this discussion.
I think the greatest risk is not from the technological end but the
human end. For instance, there was a case a couple of weeks back where
someone got stopped for a traffic ticket. Call this gentleman John Lee
Jones (I've forgotten his real name.) A routine computer check showed
James Lee Jones was a fugitive from an LA warrent, and the description
of James Lee Jones was pretty close to what John Lee Jones looked like.
So the SFPD hauled him downtown, and ran a fingerprint check to see
if there was anything else they could find out about John Lee Jones.
Turned out he had used several aliases in the past -- so the SFPD
notified the LAPD they had arrested James Lee Jones, and would the LAPD
please come up and get him? The LAPD obliged, took him down to LA,
and notified the prosecutors.
Throughout all this, Mr. Jones was (vehemently) denying he was James
Lee Jones. About a week after he had first been locked up, his public
defender persuaded the judge to order the police to compare John Lee
Jones' fingerprints with James Lee Jones' fingerprints. They didn't
match. End of case.
What's so surprising is that the people throughout the whole
proceeding did not question whether the data the computer gave them was
relevant. True, it was accurate (so far as I know.) But it was used
incorrectly. In other words, in this case the technology didn't fail;
the human safeguards did. (Incidentally, in defense of the police,
when this came out an investigation was begun to see why the
fingerprint comparison was not made immediately; according to police
procedure it should have been.) And no amount of database security can
guard against this type of breach of security.
[Caveat -- I read the newspaper story I outlined above a couple
of weeks ago in the S.F. Chronicle. I have undoubtedly misremembered
some of the details, but the thrust of it is correct.]
Matt Bishop
[Add that to the database-related cases of false arrest reported in
RISKS-1.5. PGN]
------------------------------
Date: Tue, 8 Oct 85 06:59:25 PDT
From: Murray.pa@Xerox.ARPA
Subject: Registrar's databases
To: RISKS@sri-csl.arpa
Just mentioning grades, computers and risks, all in the same paragraph
instantly brings to my mind visions of hackers who are flunking freshman
English smiling anyway, knowing that they have figured out how to get an A.
I've always assumed that everybody "knew" that students and grades couldn't
really coexist on the same machine. Does anybody know of a school
brave/silly enough to do it?
It seems like a great opportunity for somebody who makes a secure system to
get a LOT of publicity, one way or the other. Has anybody ever been
confident enough to try it? What happened?
Changing the topic slightly... Security on an ethernet is clearly
non-existent unless you encrypt everything you care about. Our personnel
people upstairs take the problem seriously. The solution is simple. They
have their own section of coax. It's not even gatewayed to the rest of our
network.
------------------------------
Date: Tue, 8 Oct 85 07:15:28 PDT
From: Murray.pa@Xerox.ARPA
Subject: Database risks - census data
To: RISKS@sri-csl.arpa
The census bureau distributes their data broken down to quite small areas. I
don't know the details, but I'm pretty sure it gets down to "neighborhood"
sized regions, and it may even get down to the block. When the sample size
gets small enough, there are obviously opportunities for gleaning
non-statistical information by using carefully crafted querys to read
between the lines.
I remember somebody telling me that they worked pretty hard to make sure
this couldn't happen. Anybody know what they actually do? Is it written up
someplace? Does it work well enough? Any war stories? Are the techniques
simple once you know the trick? ....
[As I noted in RISKS-1.19, Dorothy Denning's book is a good source.
The Census Bureau tries to add phony data that preserves all of the
overall statistics but that prevents inferences... PGN]
------------------------------
Date: Tue 8 Oct 1985 10:00:15 EST
From: William McKeeman <mckeeman%wang-inst.csnet@CSNET-RELAY.ARPA>
Subject: The winners of evolution...
To: risks@sri-csl
A recent submission included the following paragraphs on evolution
of morals...
Now I think it fairly easy to see that the capacity to put
group survival ahead of self-interest is an important genetic
trait and that tribes of people that had this trait would be
more likely to survive that tribes that didn't. That is not
to say that this moral capacity doesn't vary greatly from one
person to the next or that even that it may not be more fully
realized in one person than another because of upbringing. It
is even possible that, because of some genetic error, some
people may be born without a moral capacity, just like they
might be born without arms or legs.
Moral progress means the evolution of survival customs more
appropriate to the current context. The trouble in recent
centuries has been that our ability to evolve new technology
has outstripped our capacity to evolve the appropriate
morality for it. There is a strong tendency to stick to the
morality that one learns as a child, even if it [is] not
appropriate to the current situation.
Evolution is being used with its Darwinian meaning but with an
interpretation that includes the more ordinary progress of mankind. The
central mechanism of evolution is the failure of the less successful forms
to reproduce -- often for failing to live long enough. Evolution is never
fast enough to avoid bloodshed -- it is bloodshed that activates it. Until
disaster strikes the adapted and unadapted survive undifferentiated.
My point is that if we treat the present sad state of affairs as a problem
in evolution rather than politics or technology, we are implicitly planning
on rebuilding a world with the (apparently) adapted survivors of WWIII.
W. M. McKeeman mckeeman@WangInst
Wang Institute decvax!wanginst!mckeeman
Tyngsboro MA 01879
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂09-Oct-85 0008 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #21
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 00:05:47 PDT
Date: 8 Oct 85 2347-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #21
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 9 Oct 1985 Volume 1 : Issue 21
Today's Topics:
Administrivia
Communication and Control Structures
Reference: Coordinated Computing
Seminar: Parallel Algorithms for Form Perception (GMR)
Seminar: Recognition Algorithms for the Connection Machine (MIT)
----------------------------------------------------------------------
Date: Tue, 8 Oct 1985 23:42 PDT
From: Byron Davies <PARSYM-Request@SUMEX-AIM.ARPA>
Subject: Administrivia
So far there have been only three responses to the PARSYM Survey on
Data Abstractions for Parallel Programming. Since the survey was
highly technical in nature, I didn't expect a large number of
responses, but I was hoping for a few more than I've seen. The first
respondent, Tony Li, admitted that he wasn't doing any work on data
abstractions, but went ahead to report on some work on communications
and control structures. I've included Tony's response in this digest,
as a normal -- and much appreciated -- contribution to PARSYM. The
other two responses, by Bert Halstead of the Multilisp project at MIT
and by Dave Touretzky of the Boltzmann Machine project at CMU, will
appear when I receive at least two more responses.
By the way, in the week since the questionnaire came out, PARSYM
hasn't received many messages of any kind. Please don't let the
survey prevent you from asking questions or passing along interesting
information about parallel computing. There are lots of people (about
250 individuals plus over 30 local mailing lists or bboards) waiting
to hear from you.
While I'm in moderator mode, I'll respond publicly to a few of the
notes I've received recently. Most of the messages addressed to
PARSYM-Request are administrative requests, to add a name or remove
one or consolidate a group of names into a bboard. I've only received
a few complaints. A few weeks ago, I was asked to be more careful
about inserting editorial comments because I was breaking an
undigestifier. Never having undigestified anything, I wasn't aware of
the problem, but I've learned my lesson and I hope that undigestifiers
are gurgling happily across the country.
When Laurence Leff sent a l-o-n-g message about his establishing a
resource of technical abstracts, I had some doubts about including it
in the PARSYM digest because it wasn't about parallel computing. I
decided to go with it, however, because parallel computing, being so
new to most people, is one domain that could particularly benefit from
good communication. While I only received one complaint about this, I
want PARSYM readers to know that PARSYM is still and only the netwide
mailing list for parallel symbolic computing.
I encourage PARSYM readers to let me know what they like and dislike
about PARSYM. I'm happy to entertain suggestions about how PARSYM can
be improved or about what sorts of information you'd like to see. If
you have some suggestions for future PARSYM surveys, please let me
know.
Keep those messages and survey responses coming in!
-- Byron
------------------------------
Date: 3 Oct 1985 00:47 PDT (Thu)
From: Tony Li <Tli@Usc-Eclb>
Subject: PARSYM Digest V1 #20
1. Are you using or have you developed data structures or
abstractions specialized for parallel computing? Please
describe.
We're following the more conventional path of communications and
control structures. This may not be particularly relevant, but
anyhow...
We've developed two basic ideas. The first is bus communications.
This is distinctly similar to Channels in CSP or Occam, but with
multiple senders and receivers. Further, there is a tagging mechanism
so that processes can restrict their communications to a subset of the
possible correspondents. As with CSP, our buses are synchronous.
Our other basic idea is that of the parallel process call. This is
implemented in two separate constructs (PAR-AND and PAR-OR) which
encapsulate a number of process calls and communications statements.
PAR-AND is basically similar to a restricted COBEGIN. Multiple
processes are created and the original process blocks until all
processes have terminated and returned values. Assignment of return
values is done non-deterministically.
The PAR-OR statement terminates when any single process call or
communications statement completes. Only the completing statement is
allowed to return values (or complete an I/O operation).
Obviously, we're not too far along, and none of this is set in
concrete. I'd be happy to answer questions or listen to comments.
Cheers,
Tony ;-)
------------------------------
Date: Thursday, 3 October 1985 08:15-PDT
From: marick at GSWD-VMS
To: DAVIES at SUMEX-AIM
Re: Coordinated Computing
I hadn't heard of this book. Who's the publisher? When was it published?
[Coordinated Computing: Tools and Techniques for Distributed Software.
New York:McGraw-Hill, 1984. I highly recommend it as an introduction
to and overview of a variety of work in parallel computing. -- BD]
Thanks.
Brian Marick
Gould CSD - Urbana
------------------------------
Date: Wed, 2 Oct 85 16:00 EST
From: "S. Holland" <holland%gmr.csnet@CSNET-RELAY.ARPA>
Subject: Seminar - Parallel Form Perception (GMR)
[Forwarded from Vision-List]
General Motors Research Laboratories
Warren, Michigan
Parallel Algorithms for Form Perception
Dana H. Ballard
The University of Rochester
Rochester, New York
Thursday, October 17, 1985
ABSTRACT
Vision systems with real time performance will have to make extensive use
of parallel algorithms and computer architectures. One key problem such a
system will have to solve is the management of form. This includes shape
recognition, navigation, segmentation and object aquisition. These sub-
problems potentially can be solved in parallel by a single algorithm based
on finding rigid transformations. The talk will focus on the underlying
theory as well as computer experiments.
Dana H. Ballard received his Ph.D. in 1974 from the University of
California, Irvine. He has written numerous papers and books on computer
vision. He is presently an Associate Professor of Computer Science at the
University of Rochester.
-Steve Holland
------------------------------
Date: Fri, 4 Oct 1985 12:31 EDT
From: ELIZABETH%MIT-OZ@MIT-MC.ARPA
Subject: 9.382 -- Vision seminar
[Forwarded by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
Recognition Algorithms for the Connection Machine
Anita Flynn
Monday, October 7
Eighth Floor Playroom, A. I. Lab
4:00 pm
Many problems in early vision appear to be inherently local and
exploitble on parallel computer architectures. This talk describes a
problem in late vision, that of recognizing an unknown object and
matching it to a data base model given only sparse sensory data
points. The algorithm presently used on a sequential machine is first
explined, and then various algorithms for parallel computation are
explored. Tradeoffs in space-time efficiency are discussed in terms
of implementation on a Connection Machine. The parallel version is
shown to run three to four orders of magnitude faster than the
sequential one.
------------------------------
End of PARSYM Digest
********************
∂09-Oct-85 0155 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #42
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 01:55:09 PDT
Date: Tuesday, October 8, 1985 4:08AM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #42
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Wednesday, 9 Oct 1985 Volume 3 : Issue 42
Today's Topics:
Implementation - Destructive Assignment,
& Connected Components & Cut Tests
----------------------------------------------------------------------
Date: Mon, 30 Sep 85 09:32:42 EDT
From: Paul Hudak <Hudak@YALE.ARPA>
Subject: Prolog vs Lisp and destructive assignment
The analogy that Prolog is to Logic Programming as Lisp is to
Functional Programming is a good one. The analogy would be
even stronger if Prolog had destructive assignment, although
it's easy to argue that Prolog's Assert and Retract are forms
of destructive assignment.
However, as Peter Deutsch points out, despite our need for practical
languages, the "purists" should not give up hope that clever compiler
techniques might make pure logic or functional programming a practical
reality. For example, there now exist fairly powerful inferencing
strategies for converting call-by-need evaluation to call-by-value,
even in the presence of higher-order functions. This makes lazy
evaluation not nearly as expensive as it was once thought. As for
destructive assignment, several strategies have been developed to
infer that a purely functional update is being done to an object with
a *single reference*, so that the update can be done destructively
"behind the scenes." Papers on this topic include an early paper by
Schwartz (1978), one by Mycroft (Edinburgh thesis 1981), and a recent
one by Hudak and Bloss (POPL 85).
In the latter paper we show that if one were to translate (in the
most "obvious" way) an imperative program using destructive assign
-ment on arrays, into a purely functional program without side
effects, then it will always be the case that the updates could be
done destructively behind the scenes. The reason is rather obvious:
in an imperative program, once a change is made to an array there is
no way to access the old version of it, and the most obvious
translation to a functional program tends to preserve this property!
Indeed, this highlights precisely the *power* (rather than
disadvantage) of functional or logic programs in being able to refer
to, or "hang on" to, old objects. It is a feature that can be
simulated in conventional languages only be making explicit copies
of the array in question. (To formalize the notion of translation
we use a version of McCarthy's flowchart-schema-to-recursive-schema
translation.)
Although I haven't done it, I also believe that these results could
be generalized to logic programming.
Well, this is the good news. The bad news is that it is not clear
how one resaons about the space-efficiency of such a program, since
no inferencing strategy can guarantee that *all* copying is avoided.
I don't have an immediate solution to this problem, but am not too
concerned because:
1) In the past we have been able to educate programmers well enough
that they realize that a tail-recursive call is as space-efficient
as a loop. (Indeed, this situation can be viewed as a special
case of updating arrays!) Perhaps a similar degree of education
would help here.
2) It is possible to engineer special constructs that enforce the
single-reference property, while allowing the elegance of a purely
functional solution. Such constructs appear, for example, in
certain data-flow languages.
-- Paul Hudak
------------------------------
Date: Tue, 1 Oct 85 11:13:07 -0200
From: Ehud Shapiro <udi%wisdom.bitnet@WISCVM.ARPA>
Subject: Connected Components
In my paper, A Subset of Concurrent Prolog and its Interpreter
(ICOT TR-003), there is a Concurrent Prolog solution to the
connected components problem (which also happens to be a logic
program solution, if you delete the read-only's). Since the
program and its description are rather short, I enclose them
here.
We associate with each node in the graph a distinct integer
number. The name of a connected component is the smallest
number of any node in the component. The algorithm, for a
graph with vertices V is:
For each node n in V do
Set Xn to n.
Repeat |V| times:
Send Xn to all nodes adjacent to n,
Receive a number from every adjacent node,
Let Xn' be the minimum of Xn and the numbers received.
Set Xn to Xn'.
Set n's connected component number to Xn.
The algorithm is not very efficient. For an n-vertex graph its
computation depth is in the order of n, and its length is in the
order of n@+(2). This means, roughly, that given n processors,
the algorithm runs in linear time. Better parallel algorithms
are known (Shiloach&Vishkin), but this algorithm --- and its
implementation --- are among the simplest.
The program assumes a specialized adjacency list representation
of the graph. With each node N we associate a stream variable
Xn. The graph is represented as a list of n triples (N, Xn, As),
where N is the node number, Xn is its associated stream variable,
and As is a list of the stream variables associated with the
nodes adjacent to N.@: Given this graph, the program computes
a list of pairs (N, C), where C is the name of the connected
component of the node N.
(1) cc(Graph, CList) :-
cc(Graph, Graph, CList).
(2) cc(Graph, [(N, [N|Xn], As)|Gs], [(N, C)|Cs]) :-
node(Graph, N, Xn, As, C),
cc(Graph, Gs, Cs).
(3) cc(←, [], []).
(1) node([←|G], Xn, [Xn1|Xns], As, C) :-
min(Xn, As?, Xn1, As1), node(G, Xn1, Xns, As1, C).
(2) node([], C, [], ←, C).
(1) min(Xn, [[B|Bs]|As], Xn1, [Bs|As1]) :-
lt(Xn, B) | min(Xn, As?, Xn1, As1).
(2) min(Xn, [[B|Bs]|As], Xn1, [Bs|As1]) :-
le(B, Xn) | min(B, As?, Xn1, As1).
(3) min(Xn, [], Xn, []).
Clauses (1)-(3) spawn a node process for each node in V; note
that they generates the stream of pairs (N, C) before the
component name C of each node is determined.
Each node process has four arguments. The first is the graph
itself, which it uses to count |V| iterations. Following are
the Xn variable explained above, the list of streams of adjacent
nodes, and the node's final component number. The node process
iterates |V| times, using Clause (1), and on each iteration
performs the operations described above.
The @i(min) process extracts the smallest element among all the
first elements of the adjacent streams and the current node number,
and returns a list of the rest of the streams.
For example, if we invoke the program on the 7-vertex graph in
which 1 is connected to 2 and 3, 2 is connected to 4, 5 is
connected to no one, and 6 is connected to itself and to 7, we
get the following result:
| ?- solve(cc([(1, X1, [X2, X3]), (2, X2, [X1, X4]),
(3, X3, [X1]), (4, X4, [X2]
| (5, X5, []), (6, X6, [X6, X7]), (7, X7, [X6])], Cs)).
|
Cs = [(1, 1), (2, 1), (3, 1), (4, 1), (5, 5), (6, 6), (7, 6)],
X1 = [1, 1, 1, 1, 1, 1, 1, 1],
X2 = [2, 1, 1, 1, 1, 1, 1, 1],
X3 = [3, 1, 1, 1, 1, 1, 1, 1],
X4 = [4, 2, 1, 1, 1, 1, 1, 1],
X5 = [5, 5, 5, 5, 5, 5, 5, 5],
X6 = [6, 6, 6, 6, 6, 6, 6, 6],
X7 = [7, 6, 6, 6, 6, 6, 6, 6]
}
which shows, in addition to the component numbers, also at which
cycle each node discovered its correct component name. We see
that after three cycles every node knew its final component name.
In the paper "Distributed Programming in Concurrent Prolog"
(Weizmann Institute TR CS84-02, by A. Shafrir and myself, a
Concurrent Prolog implementation of a much more complex
distributed algorithm for connected components is described.
-- Ehud Shapiro
------------------------------
Date: Mon, 7 Oct 85 11:51:16 BST
From: mcvax!cdsm@doc.ic.ac.uk
Subject: Results of cut tests
Results of CUT Tests
I've received a large number of replies both via the network and
letters and am very grateful to all those who took the trouble
to send in results. The results as they currently stand are
listed below, and the test is also repeated (I've added a cut to
the first clause of 'do' to allow for those systems which give
all results, e.g. UNSW). As you may see, the second one listed
(all Y except for 'not' test) is numerically most popular but it
does not include any of the compiled systems. Somewhat
surprisingly, the 'Edinburgh Standard' is not a standard.
Implementation Test 1 2 3 4 5 6
DEC-10 (Comp) Y Y Y Y Y Y
Waterloo, MUprolog, Quintus(Int), Y Y Y Y Y N
UNH(1.3), Salford, Criss, Prolog-1,
BIM, York
Quintus (Int) Y Y Y Y Y I
MProlog(1.5) Y Y Y Y N N
Prolog-2 (Int, Comp) Y Y Y N N Y
DEC-10 (Int), C-Prolog, Prolog-X Y Y Y N N N
POPLOG, LM-Prolog Y Y Y I I I
Quintus (Comp) Y Y I N N N
micro, sigma Y N N Y Y N
UNSW Y N N Y N N
ICL Y N N N N N
where Y means did cut, N means did not cut and I means that it
was trapped as an illegal use and failed.
(There are several contradictory results for the Quintus
Compiler, presumably corresponding to different releases.)
If there are any other discriminating cases not covered above I
would be glad to hear of them. I would stress that I do not
consider there to be any "right" answers.
---------------------------------------------------------
/* Tests to distinguish various implementations of cut */
/* Chris Moss, Imperial College, June 1985 */
test1 :- do('Testing that cut is implemented). ', t1).
test2 :- do('Test if cut acts within disjunction', t2).
test3 :- do('Test if it cuts previous choices within disjunction',t3).
test4 :- do('Test if cut acts when passed as metacall', t4).
test5 :- do('Test if & cut acts within metacall', t5 ).
test6 :- do('Test if cut acts through not', t6).
do(Message,Test) :- w(Message), Test, !.
do(Message,Test) :- w('Does act').
w(X) :- write(X), nl.
t :- w('Does not act').
t1 :- (true;w('Did not cut alternatives correctly'),fail),
!, w('Succeeds going forwards'), fail.
t1 :- w('Failed to cut goal').
t2 :- (!;w('Fails to cut disjoint alternatives')), fail.
t2 :- t.
t3 :- t3a(X),(!,fail;w('Fails to cut disjunction')).
t3 :- t.
t3a(!).
t3a(X) :- w('Did not cut alternatives'), fail.
t4 :- t3a(X), X, w('Ok going forwards'),fail.
t4 :- t.
t5 :- t5a(X), X, fail.
t5 :- t.
t5a((true,!)).
t6 :- not(not(!)), fail.
t6 :- t.
------------------------------
Date: Mon, 7 Oct 85 11:50:20 BST
From: mcvax!cdsm@doc.ic.ac.uk
Subject: Assert/Retract tests
Tests for Assert and Retract
Below is a set of tests to look at the effects of assert and
retract along the lines of my earlier tests for cut. I would be
very grateful if anyone with access to a Prolog not listed in
the set of results which I already have could run this and send
me the results (directly) and I will post the list at some
future date in the network. So far I haven't found two
implementations which give the same results! For some
implementations, you may need to add declarations or make other
slight changes to get the desired effects.
------------------------------------------------------------
main :-
test1, test2, test3, test4, test5, test6, test7, test8, test9.
/* Tests to distinguish various implementations of assert */
test1 :- do('1. Test assert on existing predicate',t1).
test2 :- do('2. Test assert on new predicate',t2).
test3 :- do('3. Does it find added 3rd clause on backtracking', t3).
test4 :- do('4. Does it find added next (last) clause on backtracking', t4).
test5 :- do('5. Test retract on single element clause',t5).
test6 :- do('6. Does retract backtrack? ', t6).
test7 :- do('7. Does retract work on invoked clause',t7).
test8 :- do('8. Does retract work on next (last) invoked clause',t8).
test9 :- do('9. Test retracts and asserts on invoked clause', t9).
do(Message,Test) :- w(Message), Test, !.
do(Message,Test) :- w('No Clause found').
w(X) :- write(X), nl.
t :- w('Added clause').
tr :- w('Failed to retract clause').
t1 :- assert((t1a :- t)), t1a.
t1a :- w('Clause 1'),fail.
t2 :- assert((t2a :- t)), t2a.
t3 :- assert((t3:-t)),fail.
t3 :- fail.
t4 :- assert((t4:-t)),fail.
t5 :- retract((t5a :- tr)), t5a.
t5a :- tr.
t6 :- retract((t6a:-X)),fail.
t6 :- t6a.
t6a :- tr.
t6a :- w('Does not backtrack').
t7 :- t7a, fail.
t7 :- fail.
t7 :- tr.
t7a :- retract((t7:-tr)),!.
t8 :- t8a, fail.
t8 :- tr.
t8a :- retract((t8:-tr)),!.
t9 :- retract((t9:-w('Second'))),assert((t9:-t)),fail.
t9 :- w('Second').
-----------------------------------------------------
Results I already have are as follows:
1 2 3 4 5 6 7 8 9
cprolog CA A A N N N N N A
Dec-10, interpreted CA A A A N F N N A
Dec-10 compiled CN N N N N F F F S
micro prolog (CP/M-80) CA A A N E D F N A
muprolog CA A A A N N N N A
poplog CA A N N N N F F S
sigmaprolog (unix) CA A A N E D N F A
sigmaprolog (Dec front) CA A A N N F N F A
where letters stand for the first letter of the message printed
out by the test, and E stands for a "no such predicate" error
message. Note that in the latter case you may have to split up
the "main" procedure into several parts.
This set of tests is certainly not complete. In particular it
doesn't explore the interactions of assert and retract (except
for one test, 9), nor does it look at versions of assert and
retract which have numbered arguments. It's main purpose is
probably to ring the alarm bells about the differences which
have crept in and point to the need for reform. One might note
that retract together with garbage collection and reuse of an
"orphaned" pointer is the easiest way to crash many Prolog
systems. I haven't included such a test as the details appear to
differ for every implementation which is liable.
-- Chris Moss
------------------------------
End of PROLOG Digest
********************
∂09-Oct-85 0954 HANRAHAN@SU-SCORE.ARPA petty cash
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 09:53:56 PDT
Date: Wed 9 Oct 85 09:47:49-PDT
From: Katherine Hanrahan <HANRAHAN@SU-SCORE.ARPA>
Subject: petty cash
To: csd@SU-SCORE.ARPA
Stanford-Phone: (415) 497-2273
Message-ID: <12149771436.10.HANRAHAN@SU-SCORE.ARPA>
Due to an administrative delay in the accounting department there will be
no petty cash for our department until this friday, October 11th after
1:30. Sorry for any inconvenience this may cause. Katie
-------
∂09-Oct-85 1024 @SU-SCORE.ARPA:ejm@su-shasta.arpa Re: topics for prob. theory course
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 10:21:59 PDT
Received: from su-shasta.arpa by SU-SCORE.ARPA with TCP; Wed 9 Oct 85 10:18:39-PDT
Received: by su-shasta.arpa with TCP; Wed, 9 Oct 85 10:20:51 pdt
Date: Wed, 9 Oct 85 10:20:51 pdt
From: Ed McCluskey <ejm@su-shasta.arpa>
Subject: Re: topics for prob. theory course
To: MAYR@SU-SCORE.ARPA, faculty@SU-SCORE.ARPA
what'λλλλλwhat's the matter with stat116dλs?
ejmc
∂09-Oct-85 1113 @SU-SCORE.ARPA:ejm@su-shasta.arpa Re: petty cash
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 11:13:10 PDT
Received: from su-shasta.arpa by SU-SCORE.ARPA with TCP; Wed 9 Oct 85 11:06:15-PDT
Received: by su-shasta.arpa with TCP; Wed, 9 Oct 85 11:08:38 pdt
Date: Wed, 9 Oct 85 11:08:38 pdt
From: Ed McCluskey <ejm@su-shasta.arpa>
Subject: Re: petty cash
To: HANRAHAN@SU-SCORE.ARPA, csd@SU-SCORE.ARPA
there is a new policy that you are fined 200 megabucks for this
∂09-Oct-85 1349 DAVIES@SUMEX-AIM.ARPA Alliant -- Computer Systems Seminar Today!!
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 13:48:56 PDT
Date: Wed, 9 Oct 1985 13:49 PDT
Message-ID: <DAVIES.12149815420.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: Alliant -- Computer Systems Seminar Today!!
cc: Davies@SUMEX-AIM.ARPA
Date : 10/09/1985 Event : Computer Systems Seminar
Day : Wednesday Person: Craig Mundie
Time : 4:15 From : Alliant Computer Systems
Place: Terman Title : Parallel Processing with Vector Engines and
Auditorium Auto-Decomposing Compilers
According to the abstract, the architecture and system software of the
new Alliant multiprocessor will be described.
-- Byron
∂09-Oct-85 1648 admin@ucbcogsci.Berkeley.EDU Cognitive Science Seminar--Oct. 15 (Ron Kaplan, Xerox PARC & Stanford)
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 16:48:20 PDT
Received: by UCB-VAX.ARPA (5.28/5.11)
id AA05747; Wed, 9 Oct 85 16:47:54 PDT
Received: by ucbcogsci (5.28/5.12)
id AA16122; Wed, 9 Oct 85 16:48:25 PDT
Date: Wed, 9 Oct 85 16:48:25 PDT
From: admin@ucbcogsci.Berkeley.EDU (Cognitive Science Program)
Message-Id: <8510092348.AA16122@ucbcogsci>
To: cogsci-friends@ucbcogsci.Berkeley.EDU
Subject: Cognitive Science Seminar--Oct. 15 (Ron Kaplan, Xerox PARC & Stanford)
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, October 15, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Ronald M. Kaplan,
Xerox Palo Alto Research Center and Center
for the Study of Language and Information,
Stanford University
TITLE: ``Interactive Modularity''
Comprehensible scientific explanations for most complex
natural phenomena are modular in character. Phenomena are
explained in terms of the operation of separate and indepen-
dent components, with relatively minor interactions. Modular
accounts of complex cognitive phenomena, such as language pro-
cessing, have also been proposed, with distinctions between
phonological, syntactic, semantic, and pragmatic modules, for
example, and with distinctions among various rules within
modules. But these modular accounts seem incompatible with
the commonplace observations of substantial interactions
across component boundaries: semantic and pragmatic factors,
for instance, can be shown to operate even before the first
couple of phonemes in an utterance have been identified.
In this talk I consider several methods of reconciling
modular descriptions in service of scientific explanation with
the apparent interactivity of on-line behavior. Run-time
methods utilize interpreters that allow on-line interleaving
of operations from different modules, perhaps including addi-
tional "scheduling" components for controlling the cross-
module flow of information. But depending on their mathemati-
cal properties, modular specifications may also be transformed
by off-line, compile-time operations into new specifications
that directly represent all possible cross-module interac-
tions. Such compilation techniques allow for run-time elimi-
nation of module boundaries and of intermediate levels of
representation. I will illustrate these techniques with exam-
ples involving certain classes of phonological rule systems
and structural correspondences in Lexical-Functional Grammar.
--------------------------------------------------------------
UPCOMING TALKS
Oct 22: Lotfi Zadeh, Computer Science, UCB
Oct 29: Mardi Horowitz, Psychiatry, UCSF
Nov 5: Edward Zalta, CSLI, Stanford
Nov 12: Robert Wilensky, Computer Science, UCB
Nov 19: Richard Alterman, Computer Science, UCB
Nov 26: Eve Clark, Linguistics, Stanford
Dec 3: Bernard Baars, Langley Porter, UCSF
--------------------------------------------------------------
∂09-Oct-85 1656 @SU-CSLI.ARPA:admin@ucbcogsci.Berkeley.EDU Cognitive Science Seminar--Oct. 15 (Ron Kaplan, Xerox PARC & Stanford)
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 16:50:03 PDT
Received: from UCB-VAX.ARPA by SU-CSLI.ARPA with TCP; Wed 9 Oct 85 16:46:31-PDT
Received: by UCB-VAX.ARPA (5.28/5.11)
id AA05747; Wed, 9 Oct 85 16:47:54 PDT
Received: by ucbcogsci (5.28/5.12)
id AA16122; Wed, 9 Oct 85 16:48:25 PDT
Date: Wed, 9 Oct 85 16:48:25 PDT
From: admin@ucbcogsci.Berkeley.EDU (Cognitive Science Program)
Message-Id: <8510092348.AA16122@ucbcogsci>
To: cogsci-friends@ucbcogsci.Berkeley.EDU
Subject: Cognitive Science Seminar--Oct. 15 (Ron Kaplan, Xerox PARC & Stanford)
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, October 15, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: Ronald M. Kaplan,
Xerox Palo Alto Research Center and Center
for the Study of Language and Information,
Stanford University
TITLE: ``Interactive Modularity''
Comprehensible scientific explanations for most complex
natural phenomena are modular in character. Phenomena are
explained in terms of the operation of separate and indepen-
dent components, with relatively minor interactions. Modular
accounts of complex cognitive phenomena, such as language pro-
cessing, have also been proposed, with distinctions between
phonological, syntactic, semantic, and pragmatic modules, for
example, and with distinctions among various rules within
modules. But these modular accounts seem incompatible with
the commonplace observations of substantial interactions
across component boundaries: semantic and pragmatic factors,
for instance, can be shown to operate even before the first
couple of phonemes in an utterance have been identified.
In this talk I consider several methods of reconciling
modular descriptions in service of scientific explanation with
the apparent interactivity of on-line behavior. Run-time
methods utilize interpreters that allow on-line interleaving
of operations from different modules, perhaps including addi-
tional "scheduling" components for controlling the cross-
module flow of information. But depending on their mathemati-
cal properties, modular specifications may also be transformed
by off-line, compile-time operations into new specifications
that directly represent all possible cross-module interac-
tions. Such compilation techniques allow for run-time elimi-
nation of module boundaries and of intermediate levels of
representation. I will illustrate these techniques with exam-
ples involving certain classes of phonological rule systems
and structural correspondences in Lexical-Functional Grammar.
--------------------------------------------------------------
UPCOMING TALKS
Oct 22: Lotfi Zadeh, Computer Science, UCB
Oct 29: Mardi Horowitz, Psychiatry, UCSF
Nov 5: Edward Zalta, CSLI, Stanford
Nov 12: Robert Wilensky, Computer Science, UCB
Nov 19: Richard Alterman, Computer Science, UCB
Nov 26: Eve Clark, Linguistics, Stanford
Dec 3: Bernard Baars, Langley Porter, UCSF
--------------------------------------------------------------
∂09-Oct-85 1703 EMMA@SU-CSLI.ARPA Newsletter October 10, No. 49
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 17:03:09 PDT
Date: Wed 9 Oct 85 16:51:08-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter October 10, No. 49
To: friends@SU-CSLI.ARPA
Tel: 497-3479
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
October 10, 1985 Stanford Vol. 2, No. 49
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, October 10, 1985
12 noon TINLunch
Ventura Hall ``Artificial Intelligence Meets Natural Stupidity''
Conference Room by Drew McDermott
Discussion led by Roland Hausser, U. of Munich
(Abstract on page 1)
2:15 p.m. CSLI Seminar
Redwood Hall ``Ontology and Intensionality''
Room G-19 Edward Zalta, CSLI
Discussion led by John Perry
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, October 17, 1985
12 noon TINLunch
Ventura Hall ``Economy of Speech Gestures''
Conference Room by Bjorn Lindblom (who will be present)
Discussion led by Bill Poser
(Abstract on page 2)
2:15 p.m. CSLI Seminar
Redwood Hall ``On the Notion of `Logophoricity' ''
Room G-19 Peter Sells, CSLI
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
ABSTRACT FOR THIS WEEK'S TINLUNCH
Artificial Intelligence Meets Natural Stupidity
McDermott discusses three `mistakes', or rather bad habits, which are
frequent in A.I. work. He speaks from his own experience and cites
several illuminating and amusing examples from the literature. In this
TINLunch I will be discussing his thoughts on treating reference in
A.I., which are discussed in the section entitled `unnatural
language'. --Roland Hausser
!
Page 2 CSLI Newsletter October 10, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S TINLUNCH
Economy of Speech Gestures
This paper discusses a functionalist approach to phonetics and
phonology in which the properties of phonological systems are to be
deduced from biological and social factors rather than from from
axioms governing a language-particular formal system. --Bill Poser
←←←←←←←←←←←←
ABSTRACT FOR NEXT WEEK'S SEMINAR
On the Notion of `Logophoricity'
The notion of `logophoricity' was introduced in studies of African
languages in which a morphologically distinct `logophoric' pronoun has
a distribution distinct from other pronouns, used with predicates of
communication and consciousness. More recently, this notion has been
used in accounts of anaphora with non-clause-bounded reflexive
pronouns, as are found in the Scandinavian languages, and Japanese.
Such analyses propose a feature [+log] which is supposed to be
specified on certain NPs by certain predicates. I will present the
beginnings of a formal construction of the notion of `logophoricity'
using the Discourse Representation Structures framework developed by
Hans Kamp. I will propose that there is no such thing as
logophoricity per se, but rather that it stems out of the interaction
of two more primitive notions: the person with respect to whose
consciousness (or `SELF') the report is made, and the person from
whose point-of-view the report is made (the `PIVOT'). I will show how
this system extends to certain facts (from Japanese) which are not
analyzable with the simple feature [+log], and how it enables one to
characterize cross-linguistic variation in what counts for
`logophoricity'. --Peter Sells
←←←←←←←←←←←←
ENVIRONMENTS GROUP MEETING
Monday, October 14, noon, Ventura Trailer Classroom
David Levy (Xerox PARC and CSLI) will continue to describe his work
on a theoretical foundation for document preparation environments.
Specifically, he will describe in some detail the theory of marking
itself, and its relevance to various computer systems. We will
discuss some points that came up in questions, such as the relation of
``indirect marking'' to different kinds of tools, the contrast between
a psychological theory (how people think when they use a system) and
an ontological account (of the basic objects, actions, and
relationships that are available for them to work with), and the
problems of multiple levels of representation (e.g., a macro command
stands for a sequence of ``characters'' which in turn represent
various ``figures'', etc.).
See the summary of the meeting on October 7 (later in this
newsletter) for more information.
←←←←←←←←←←←←
LINGUISTICS COLLOQUIUM
``Underspecification and Opacity''
Douglas Pulleyblank, USC
Tuesday, October 15, Bldg. 200, Rm. 217, 3:15 p.m.
!
Page 3 CSLI Newsletter October 10, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
LOGIC SEMINAR
``Computability of Standard Processes in Analysis and Physics''
Marian Pour-El, University of Minnesota
Monday, October 14, Noon to 1:15
Ventura Hall Seminar Room
Note the change of time and place.
The regular meeting time of this seminar has been changed to
Friday, noon. We will meet alternate weeks beginning Friday, October
25. --Sol Feferman
←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
Summary of the meeting on September 26
Farrell Ackerman gave a talk entitled ``Brackets and Branches:
Phrasal Verbs.'' Assuming a provisional (and, perhaps, traditional)
definition of phrasal verbs as morpholexically composed entities whose
constitutive pieces exhibit syntactic independence, the discussion
focused on the syntactic and lexical aspects of these Janus-like
elements.
From a syntactic perspective the interaction of phrasal verbs and
rule of V(erb)-movement in, e.g., Vata (a Kru language analyzed in
Koopman 1983) was discussed. V-movement in Vata is one particular case
of V-movement motivated along similar lines, i.e., hypothesizing a V
final d-structure representation, for the Germanic languages German
and Dutch. Evidence of similar syntactic discontinuities between
particles (called `preverbs') and associated verb stems was given for
the Ugric language Hungarian. On the other hand, it was suggested
that in this instance it is not the V but the particle which `moves.'
After a presentation of the preverb-verb sequence possibilities in
Hungarian discussion turned to the lexical aspects of preverb-verb
collocations.
From a lexical perspective the set of Hungarian preverbs can be,
roughly, divided into two groups: prefixes and arguments. The
prefixes (minus a class of intriguing exceptions which were not
discussed ) are categorially indeterminate and do not exhibit
inflectional morphology indicating any relation of the prefix with the
verb. Arguments, in contrast, are categorially determinable (in fact,
are typically instantiated by and restricted to appear as a major
lexical category) and bear inflectional morphology indicating their
grammatical relation to the verb. The combination of prefix + verb
was hypothesized to be a type of verb derivation via prefixation while
argument + verb was regarded as a type of lexical compounding.
Evidence for the lexical nature of these phrasal verbs was taken to be
their ability to serve as input for further derivational processes
such as nominalization and adjectivilization.
The assumption that phrasal verbs are lexical compositions leads to
problems for the so-called Lexical Integrity Hypothesis, the procedure
of Bracket Erasure in Lexical Phonology and, in general, leads to what
have become know as `Bracketing Paradoxes.' It was proposed (following
Simpson 1983 and Komlosy and Ackerman 1983) that there is a process of
`bracket retention' restricted to the domain of predicate formation
which accounts for the main difference, i.e., the syntactic
separability of preverbs, in the behavior of preverbs in numerous
languages.
!
Page 4 CSLI Newsletter October 10, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
SUMMARY OF ENVIRONMENTS GROUP MEETING
September 30, 1985
At the first meeting of the environments group we set out the
general directions for our discussions. We identified some major
dimensions along which to compare and examine environments and made an
initial list of examples that might be presented. This list is very
sketchy---the random result of what happened to come up in
conversation. We are eager for further details and suggestions
(either systems for general consideration, or about which specific
people would like to talk):
Programming environments: Interlisp, Smalltalk, Cedar, [all 3 Xerox],
(Linton) [Berkeley/Stanford], Gandalf [CMU], Mentor [INRIA],
ZetaLisp [Symbolics], Kee [Intellicorp], HPRL, HPLisp [last 2
Hewlett-Packard]
Grammar development environments: LFG [CSLI], HPSG [HP], BLT [CSLI],
Specification environments: Aleph [CSLI], (Balzer)[ISI]
Language development environments: MUIR [CSLI]
Document preparation environments: (Levy) [CSLI], Notecards [Xerox]
Data access and manipulation environments:
Mathematical and logical deduction environments: MACSYMA [MIT], FOL
[Stanford]
There is a variety of application areas not as central to CSLI
concerns, but in which environments are built. These include VLSI
design, CAD/CAM, image manipulation, mail systems, etc. In addition,
most operating systems take on the functions of an environment, either
for use outside of applications programs or as a base within them.
So-called ``intelligent agents'' are one attempt to provide a uniform
environment for a particular user interacting with multiple systems.
For each kind of environment there are specific problems dealing
with the particular structures being worked with (programs, proofs,
grammars, formatted documents, etc.). There is also a framework of
common problems having to do with the basic structure of items being
manipulated (text, trees, databases, etc.), their representation on a
screen or hardcopy, interfaces for operating through that
representation, storage on one or more devices, consistency between
aspects (e.g., source and compiled code, specifications and proofs),
change over time (versions, releases, etc.), coordination of access
among a group, etc.
Our plan is to address the basic conceptual issues by looking at
one particular environment or group of related environments in each
session.
!
Page 5 CSLI Newsletter October 10, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
SUMMARY OF ENVIRONMENTS GROUP MEETING
October 7, 1985
David Levy gave an overview of his work on a theoretical basis for
document preparation environments. He demonstrated the problems with
existing ``marking environments'' which combine conflicting approaches
to text layout, drawing, and window placement. The failure to
generalize the common elements in all of these leads to greater
complexity and to blind spots that create difficulty in maintaining,
documenting, and using such systems. Many of the relevant issues
apply to older marking technologies, but the computer has two novel
properties that demand a clear and explicit theory. First, marking is
indirect---the linkage between human physical action and what appears
on the screen (or paper) is mediated by linguistic or quasi-linguistic
commands. Second, there is a clear distinction between the surface
presentation (what you see) and the internal representation (its
underlying structure). The computer, unlike earlier forms, lets you
manipulate the underlying structure directly, with possibly complex
and distributed consequences to the surface presentation.
He then showed how we might begin to develop a theory of marking
with a coherent ontological basis. For example, we need to look at
something as mundane as the ``carriage return'' as having distinct and
sometimes confused aspects: it is a character (in the standard
representation), it denotes an area of non-marked space on a page, it
indicates a possible place to split a line in normal formatting, etc.
By carefully delineating the concepts involved in these different
aspects, we can produce systems that are simpler, easier to
understand, and more amenable to generalization.
←←←←←←←←←←←←
LICS CONFERENCE
A new conference, LICS, (an acronym for ``Logic in Computer
Science'') will meet in Cambridge, Mass, June 16-18, 1986. The topics
to be covered include abstract data types, computer theorem proving
and verification, concurrency, constructive proofs as programs, data
base theory, foundations of logic programming, logic-based programming
languages, logics of programs, knowledge and belief, semantics of
programs, software specifications, type theory, etc. For a local copy
of the full call for papers, contact Jon Barwise (Barwise@CSLI) or
Joseph Goguen (Goguen@SRI-AI), members of the LICS Organizing
Committee.
!
Page 6 CSLI Newsletter October 10, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
COMMON SENSE AND NON-MONOTONIC REASONING SEMINARS
Organized by John McCarthy and Vladimir Lifschitz
Computer Science Dept., Stanford University
A series of seminars on Common Sense and Non-monotonic reasoning
will explore the problem of formalizing commonsense knowledge and
reasoning, with the emphasis on their non-monotonic aspects.
It is important to be able to formalize reasoning about physical
objects and mental attitudes, about events and actions on the basis of
predicate logic, as it can be done with reasoning about numbers,
figures, sets and probabilities. Such formalizations may lead to the
creation of AI systems which can use logic to operate with general
facts, which can deduce consequences from what they know and what they
are told and determine in this way what actions should be taken.
Attempts to formalize commonsense knowledge have been so far only
partially successful. One major difficulty is that commonsense
reasoning often appears to be non-monotonic, in the sense that getting
additional information may force us to retract some of the conclusions
made before. This is in sharp contrast to what happens in
mathematics, where adding new axioms to a theory can only make the set
of theorems bigger.
Circumscription, a transformation of logical formulas proposed by
John McCarthy, makes it possible to formalize non-monotonic reasoning
in classical predicate logic. A circumscriptive theory involves, in
addition to an axiom set, the description of a circumscription to be
applied to the axioms. Our goal is to investigate how commonsense
knowledge can be represented in the form of circumscriptive theories.
John McCarthy will begin the seminar by discussing some of the
problems that have arisen in using abnormality to formalize common
sense knowledge about the effects of actions using circumscription.
His paper Applications of Circumscription to Formalizing Common Sense
Knowledge is available from Rutie Adler 358MJH. This paper was given
in the Non-monotonic Workshop, and the present version, which is to be
published in Artificial Intelligence, is not greatly different. The
problems in question relate to trying to use the formalism of that
paper.
The seminar will replace the circumscription seminar we had last
year. If you were on the mailing list for that seminar then you will
be automatically included in the new mailing list. If you would like
to be added to the mailing list (or removed from it) send a message to
Vladimir Lifschitz (VAL@SAIL).
The first meeting is in 252MJH on Wednesday, October 30, at 2pm.
-------
∂09-Oct-85 1705 AAAI-OFFICE@SUMEX-AIM.ARPA Cog Science Society Proposal
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 17:05:23 PDT
Date: Wed 9 Oct 85 17:01:08-PDT
From: AAAI <AAAI-OFFICE@SUMEX-AIM.ARPA>
Subject: Cog Science Society Proposal
To: officers: ;
cc: aaai-OFFICE@SUMEX-AIM.ARPA
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12149850319.12.AAAI-OFFICE@SUMEX-AIM.ARPA>
My response to the the Cognitive Science Society Proposal is that the
office can do it with some reservations. Although the Cognitive
Science Society has approximately 700 members (which is less than 7%
of our membership of ~9,750 members) we foresee that the initial
start-up will take approximately 6 working days of our time to update
their files (only after they have rewrite their membership management
programs and convert their database files into MS-DOS DBase II or III
file format; this task will take some time and effort, which they will
be financially responsible for). We then anticipate once a week (8
hours) maintenance of their database. If we were to establish a
formal arrangement (as opposed to a trial run) we would be expected and
responsible for the opening of their mail and the depositing of dues
into a local Menlo Park account; we can expect to spend about 16 hours
a month on that task. In addition, we will need to spend some time
setting up the account and cost center with our accountant.
They have also asked us to duplicate and mail 6 mailings a year; we
will have an outside mailing house perform that task and direct bill
them. I intend to charge all our direct labor charges to the
Cognitive Science Society on a monthly basis. They have also asked us
to send and count their election ballots; I personally think that the
Secretary-Treasurer of their organization should be responsible for
the counting of the ballots, not the AAAI.
This office's principal responsibilities are to implement the services
and programs of the AAAI. When the conference months arrive
(March-August), we spend all our time on the conference and the
maintenance of the membership database (heaviest renewal months are
July-Sept). It would appear that additional staffing would be
required to keep abreast of the Cognitive Science Society's needs
during this period, because our staff will be working on the
conference and membership exclusively. The Cognitive Science Society
should not expect the best of service during this period.
During the rest of the year, I do believe we will be able maintain
their database with the caveat that the database remains relatively
small. Our membership is growing at a rate of 200 new members per
month with an overall attrition rate of less than 8% per year; we now
have 9,750 members. Our clerical staff is just able to maintain the
current sized database.
My recommendation is to try it for one year and see how it taxes the
staff. However, I do strongly believe that cooperation with the Cog
Sci Society must go well beyond their current proposal. Other forms
of scientific cooperation and collaboration (eg. Hart's suggestion for
jointly sponsored workshops) should be part and parcel of our agreement
with Cog SCi in the future.
--- Claudia
-------
∂09-Oct-85 1915 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA Call for Papers, Spring'86 CUG
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 9 Oct 85 19:15:28 PDT
Received: from ames-vmsb.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Oct 85 19:10:40-PDT
Date: 9 Oct 85 17:56:00 PST
From: welch@ames-vmsb.ARPA
Subject: Call for Papers, Spring'86 CUG
To: super@su-score.arpa
Reply-To: welch@ames-vmsb.ARPA
The next meeting of the Cray User's Group has begun seeking papers.
The theme of the next meeting is Unix. Papers need not emphasize the
theme but can also cover other standard Cray topics such as COS, CTSS,
CFT, and day to day operations as well. The meeting is being sponsered
by Boeing Computer Services. All papers should come from people working
at Cray affiliated sites. Sites not already possessing Crays but
considering purchase of a Cray may contact David Lexton at the address
below for special approval. The keynote speaker will be a prominent member
of the Unix community currently involved with Cray.
--eugene miya
NASA Ames Research Center
eugene@ames-nas.ARPA
{hplabs,ihnp4,hao,nsc,menlo70,decwrl}!ames!amelia!eugene
Software Tools Special Interest Committee, CUG
Session Chair on the C Programming Language, Spring'86 CUG
{send me C related papers for direct review}
------------------------ Please tear here ---------------------------
CUG
CALL for PAPERS
SEATTLE, WA MAY 5-8 1986
THEME: UNIX
NAME:
ORGANIZATION:
ADDRESS:
TELEPHONE: ( )
TITLE OF PAPER:
TWO OR THREE SENTENCE ABSTRACT:
EQUIPMENT REQUIRED OTHER THAN 35MM SLIDE PROJECTOR OR OVERHEAD PROJECTOR:
SUGGESTED SESSION:
GENERAL SESSION ←←← LANGUAGES ←←←
I/O ←←← LIBRARIES ←←←
FRONT ENDS ←←← MULTITASKING ←←←
NETWORKING ←←← OPTIMIZATION ←←←
OPERATIONS ←←← PERFORMANCE EVALUATION ←←←
OPERATING SYSTEMS ←←← APPLICATIONS ←←←
GRAPHICS ←←← DATA MANAGEMENT ←←←
OTHER: ←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
RETURN BY JANUARY 1, 1986 to:
DAVID LEXTON
University of London Computer Centre
20 Guilford Stree
London WC1N 1DZ England
------
∂09-Oct-85 2015 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ucbernie.Berkeley.EDU
Received: from [36.36.0.196] by SU-AI.ARPA with TCP; 9 Oct 85 20:15:20 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 9 Oct 85 20:12:14-PDT
Received: from UCB-VAX.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Oct 85 20:12:06-PDT
Received: by UCB-VAX.ARPA (5.28/5.11)
id AA01898; Wed, 9 Oct 85 14:06:41 PDT
Received: by ucbernie.ARPA (5.28/5.6)
id AA06900; Wed, 9 Oct 85 14:05:09 PDT
Date: Wed, 9 Oct 85 14:05:09 PDT
From: karp@ucbernie.Berkeley.EDU (Richard Karp)
Message-Id: <8510092105.AA06900@ucbernie.ARPA>
To: aflb.all@su-score.arpa, allmsgs@ernie.Berkeley.EDU,
csfac@ernie.Berkeley.EDU, theory-b@ernie.Berkeley.EDU,
theory@ernie.Berkeley.EDU
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley (415)642-0143
WORKSHOP ON COMPUTATION IN ALGEBRA AND NUMBER THEORY
October 14-18, 1985
All lectures will take place in the MSRI Lecture Hall.
Monday, October 14
Hendrik Lenstra, "Factoring Integers With Elliptic Curves" 9:30
Carl Pomerance, "Integer Factoring Algorithms" 11:00
Don Coppersmith, "Solution of Sparse Systems of Linear Equations over Finite
Fields" 2:00
Jeffrey Lagarias, "Multidimensional Continued Fraction Algorithms" 4:00
Tuesday, October 15
Joachim von zur Gathen, "Deterministic Factorization of Polynomials" 9:00
Erich Kaltofen, "Multivariate Polynomial Factorization: from Curves to
Vandermonde Determinants" 10:30
George Andrews, "Scratchpad and Rogers-Ramanujan Type Identities" 2:00
Andrew Odlyzko, "On the Complexity of the Riemann Zeta Function"
Wednesday, October 16
Susan Landau, "Polynomial Time Algorithms for Solvable and Simple Galois
Groups" 9:00
John McKay, "The Computation of Galois Groups" 10:30
Gary Miller, "Permutation Groups and their Relation to Graph
Isomorphisms" 2:00
Eugene Luks, "Polynomial Time Computation in Permutation Groups" 4:00
Thursday, October 17
Barry Trager, "Integral Bases and Nonsingular Models of Curves" 9:00
Patrizia Gianni, "Ideal Theoretic Operations Using Grobner Bases" 10:30
David Bayer, "On the Geometry of Computing Syzygies" 2:00
Michael Stillman, "Castelnuovo Regularity and the Complexity of Computing
Syzygies" 4:00
Friday, October 18
Stephen Wolfram, Cellular Automata" 9:00
Laszlo Lovasz, "Algorithmic Problems on Algebraic Matroids" 10:30
∂10-Oct-85 0904 LIBRARY@SU-SCORE.ARPA Socrates: Are people having problems when they attempt to telnet to Socrates?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 09:04:43 PDT
Date: Thu 10 Oct 85 09:01:54-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: Are people having problems when they attempt to telnet to Socrates?
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12150025222.27.LIBRARY@SU-SCORE.ARPA>
Someone has brought to my attention that when they telnet to Forsythe and then
try to logon to Socrates they are immediately logged off. Are others having
the same problem? If so, send me a message with subject header Socrates Logon
Problem, identify the computer you are attempting to telnet from and indicate
briefly exactly what is happening, or not happening.
Harry Llull
-------
∂10-Oct-85 1107 DELAGI@SUMEX-AIM.ARPA "Volunteers"
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 11:07:14 PDT
Date: Thu 10 Oct 85 11:07:54-PDT
From: Bruce Delagi <DELAGI@SUMEX-AIM.ARPA>
Subject: "Volunteers"
To: aap@SUMEX-AIM.ARPA
Message-ID: <12150048159.66.DELAGI@SUMEX-AIM.ARPA>
As mentioned yesterday, there's about 1.5 sessions worth of formal lecture
for the three meetings on parallel KBS hardware systems architecture. The
remaining 1.5 sessions will be devoted to presentations by seminar attendees.
There are five presentations needed. The idea is to use the lecture material
to assess some alternative machines in terms of the design choices they
represent. For October 21st, the representative machines are [1] the HEP,
[2] the Cosmic Cube, and [3] the RPP-3. For October 28th, two presentations
will force a contrast between [4] dataflow machines and languages and [5]
parallelizing compilers for conventional languages. I think this can be best
done by the presenters taking the proponent's position [respectively for
Arvind/Dennis/Gurd and Gajski/Kuck] using the arguments developed in the
papers for the 28th and the lectures and discussions on the 14th and 21st.
Presentations on the HEP, the Cosmic Cube, and the RPP-3 should be pretty
short: say 10 minutes or so. The data flow / dusty deck debate leaders
should prepare a statement of position [10 minutes] and a rebuttal [shorter]
exposing the issues as clearly as possible for a discussion to follow.
Volunteers please...................../bruce
-------
∂10-Oct-85 1357 LIBRARY@SU-SCORE.ARPA [The Mailer Daemon <Mailer@SU-SCORE.ARPA>: Message of 10-Oct-85 13:49:31]
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 13:56:21 PDT
Date: Thu 10 Oct 85 13:51:18-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: [The Mailer Daemon <Mailer@SU-SCORE.ARPA>: Message of 10-Oct-85 13:49:31]
To: : ;
Message-ID: <12150077903.27.LIBRARY@SU-SCORE.ARPA>
Date: Thu 10 Oct 85 13:49:34-PDT
From: The Mailer Daemon <Mailer@SU-SCORE.ARPA>
To: LIBRARY@SU-SCORE.ARPA
Subject: Message of 10-Oct-85 13:49:31
Message failed for the following:
facutly@SU-SCORE.ARPA.#Internet: No such mailbox
------------
Date: Thu 10 Oct 85 13:49:31-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books
To: su-bboards@SU-SCORE.ARPA
cc: facutly@SU-SCORE.ARPA
Message-ID: <12150077580.27.LIBRARY@SU-SCORE.ARPA>
A Hierarchical Associative Processing System. by Heinrich J. Stuttgen.
Lecture Notes In Computer Science. no. 195 TK7895.M4S78 1985.
Automata On Infinite Words. Ecole de Printemps d'Informatique Theorique
Le Mont Dore, May 1984. ed. by M. Nivat and D. Perrin.
QA267.E26 1984.
Applications of Artificial Intelligence II. Proceedings of SPIE. ed.
John Gilmore. Q334.A663.
User Interface Management Systems. Eurographic Serminars. ed. Gunther
Pfaff. QA76.9.I58W67 1983.
Introducing Artificial Intelligence. by G.L. Simons. National Computing
Centre Publication.(8512444)
Programmierung Paralleler Prozesse. by Bachmann. Technische Universitat
Dresden. Weiterbildungszentrum Fur Mathematische Kybernetik Und
Rechentechnik/Informationsverarbeitung. (8508714)
Discrete Mathematics And Applied Modern Algebra. by Henry Laufer.
QA162.L38 1984.
Topics In The Theory Of Computation. Annals of Discrete Mathamatics. No.24.
by Marek Karpinski and Jan Van Leeuwen. QA267.I56 1983.
STATCOMP 83 Papers. A Symposium on Statistical Packages, Microcomputers and
Database Management. (8508548)
TIMSAC-88 Part 1 and Part 2. Computer Science Monographs. A Publication
of The Institute of Statistical Mathematics. (8517294)
H. Llull
-------
-------
-------
∂10-Oct-85 1408 CAROL@SU-CSLI.ARPA New office
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 14:07:54 PDT
Date: Thu 10 Oct 85 14:02:14-PDT
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: New office
To: Folks@SU-CSLI.ARPA
cc: Carol@SU-CSLI.ARPA
Hi-
I have just moved from F-2 to luxurious quarters in Ventura 28
(second floor behind the stairs). So far there's no phone, but
Jamie has kindly offered to share his - 7-3170.
-Carol
-------
∂11-Oct-85 0042 NEUMANN@SRI-CSL.ARPA RISKS-1.21
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 00:42:36 PDT
Date: Thu 10 Oct 85 23:27:02-PDT
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSL.ARPA>
Subject: RISKS-1.21
Sender: NEUMANN@SRI-CSL.ARPA
To: RISKS-LIST@SRI-CSL.ARPA
RISKS-LIST: RISKS-FORUM Digest Thursday, 10 Oct 1985 Volume 1 : Issue 21
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Public Accountability (Jim Horning, Peter Neumann)
The Titanic Effect (JAN Lee)
Databases, Grades, etc. (Brian Borchers, Andy Mondore, Mark Day [twice],
Alan Wexelblat, Ross McKenrick, Randy Parker)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions should
be relevant to the topic, technically sound, objective, in good taste, and
coherent. Others will be rejected. Diversity of viewpoints is welcome.
Please try to avoid repetition of earlier discussions.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
From: horning@decwrl.ARPA (Jim Horning)
Date: 10 Oct 1985 1244-PDT (Thursday)
To: RISKS@SRI-CSL
Subject: Public Accountability
It has now been more than a year since the ACM Council passed its
resolution on computer systems and risks to the public. Quoting from
RISKS-1.1:
The second part of the resolution includes a list of technical questions
that should be answered about each computer system. This part states that:
While it is not possible to eliminate computer-based systems failure
entirely, we believe that it is possible to reduce risks to the public
to reasonable levels. To do so, system developers must better
recognize and address the issues of reliability. The public has the
right to require that systems are installed only after proper steps
have been taken to assure reasonable levels of reliability.
The issues and questions concerning reliability that must be addressed
include:
1. What risks and questions concerning reliability are involved when
the computer system fails?
2. What is the reasonable and practical level of reliability to
require of the system, and does the system meet this level?
3. What techniques were used to estimate and verify the level of
reliability?
4. Were the estimators and verifiers independent of each other
and of those with vested interests in the system?
In the intervening year, I am not aware that the developers of ANY
computer system have made public their answers to these four questions.
Readers of this forum will surely not leap to the conclusion that no
computer system presents risks to the public worthy of discussion.
I would like to start a discussion on how we can change this.
What can we do as professionals to make it the norm for system
developers to present risk assessments to the public?
* What can we do to make it more attractive to present a risk assessment?
- Explicitly invite developers of particular systems to publish draft
assessments here in the RISKS Forum, with the promise of constructive
feedback.
- Inaugurate a section in CACM for the publication of refined risk
assessments of systems of great public interest or importance.
- Publish the risk assessments without refereeing. This gives the
developers "first shot," gets the material out more quickly, and lowers
the barrier to publication, without limiting the opportunity for public
discussion and debate.
- Encourage developers to also address John McCarthy's question:
5. What are the risks inherent in the best available alternative
to the system in question?
- Encourage the exploration of legal steps that would make
Risk Assessments as routine as Environmental Impact Statements.
(This could be useful even if most of the former are as pro forma and
unenlightening as most of the latter; they provide a starting point.)
* What can we do to make it less attractive not to present a risk assessment?
- First, make it very clear that we, as a profession, believe that it
is incumbent on system developers to present their risk assessments,
and that delay or refusal amounts to malpractice of a very high order.
- Periodically publish (and publicize) the status of all outstanding
invitations to present risk assessments.
- Bring cases of persistent noncompliance to the attention of ACM
Council for appropriate action.
I present these suggestions as a springboard for discussion, not as a
definitive program for action. I welcome suggestions for improvement.
Jim H.
------------------------------
Date: Thu 10 Oct 85 13:30:24-PDT
From: Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Subject: Public Accountability
To: RISKS@SRI-CSL.ARPA
cc: Horning@DECWRL.DEC.COM
Perhaps we can learn something from some steps that have been taken by the
National Computer Security Center (although for security and not
reliability). The NCSC (formerly the DoD CSC) has established a set of
criteria for trusted computer systems, in the form of a range of
increasingly stringent requirements. They have evaluated various systems
against those criteria. They have also explored what kinds of applications
should have which requirements. To date, two systems have been accorded
high rankings: (1) the highest existing rating [A1] to the Honeywell SCOMP
-- whose kernel design and trusted subsystems have undergone formal design
proofs demonstrating that the kernel specifications satisfy a security
condition of no adverse flow, and that the trusted subsystems satisfy other
relevant properties involving privilege, integrity, and functional
correctness; (2) a somewhat lower rating [B2] to Multics, which has not been
subjected to any formal analysis, but which satisfies certain of the
hardware and software-engineering criteria and which has withstood extensive
penetration attacks. Other systems have also been evaluated, but given
lesser ratings -- implying greater potential security risks. (The NCSC also
publishes an Evaluated Products List.) The literature on this subject is
extensive, but I note a few items here on the Criteria and on the SCOMP
proofs. Other than that, you can look at the IEEE Proceedings for the
Security and Privacy conferences each April and the National Computer
Security Conferences held at NBS roughly once a year (previously called the
DoD/NBS Computer Security Conference).
I of course need to add that the work on secure and trusted computing
systems is only a very small part of that addressing the potential "risks to
the public", which of course also involve reliability in various forms,
human safety, timely responsiveness, etc. But my point is that some steps
in the right direction are actually being taken in the security community --
although those are still only small steps with respect to the overall
problem. Nevertheless, something can be learned from the security work
in addressing the ACM goals that Jim has reminded us of once again.
So, let us try to address some of Jim's points specifically in the future.
REFERENCES:
CRITERIA: Department of Defense Trusted Computer System Evaluation
Criteria, CSC-STD-001-83. Write to Sheila Brand, National Computer
Security Center, Ft Geo G Meade MD 20755. (SBrand@MIT-Multics)
SCOMP KERNEL DESIGN PROOFS: J.M. Silverman, Reflections on the Verification
of the Security of an Operating System, Proceedings of the 9th ACM Symposium
on Operating Systems Principles, October 1983, pp. 143-154.
SCOMP TRUSTED SUBSYSTEM DESIGN PROOFS: T.C.V. Benzel and D.A. Tavilla,
Trusted Software Verification: A Case Study, Proceedings of the 1985
Symposium on Security and Privacy, IEEE Computer Society, Oakland CA, April
1985, pp. 14-31.
(Note: In a proof of design consistency, the proof must show that a formal
specification satisfies a set of requirements, e.g., for security or fault
tolerance. The difference between requirements and specifications in that
case is generally that the former tend to be simply-stated global
properties, while the latter tend to be detailed sets of constraints defined
[e.g.,] functionally on state transitions or algebraically on inputs and
outputs.)
----------------------------------------------------------------------
Date: Tue, 8 Oct 85 16:26 EST
From: Jan Lee <janlee%vpi.csnet@CSNET-RELAY.ARPA>
To: RISKS@sri-csl.arpa
Subject: The Titanic Effect
THE TITANIC EFFECT (Source unknown):
The severity with which a system fails is directly proportional
to the intensity of the designer's belief that it cannot.
COROLLARY:
The quantity and quality of built-in redundancy is directly
proportional to the degree of concern about failure.
JAN
----------------------------------------------------------------------
Date: Wed, 9 Oct 85 09:43:20 EDT
From: Brian←Borchers%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
To: risks@sri-csl.arpa
Subject: Databases, Grades, etc.
Here at RPI, The Registrar's database, as well as the Bursar's systems are
on the same machine that we use for academic work. We've put a lot of
effort into making MTS secure...
[By the way, some of this issue's discussions on the low risks of putting
grades on student computers reflect overall a benevolent naivete about
the system security risks. I have not tried to comment on each message
individually, but find them intriguing. One could turn the students
loose to see how many flaws they can find, perhaps as a part of a
course: give them all F's in the database, and let them try to earn
their A's by breaking in! On the other hand, you might find the last
one who breaks changes some of the A's to F's! It is dangerous to
announce in public that you as an administrator believe you have made
unauthorized alterations difficult or impossible; knowing how badly
flawed most of the systems are, that is a very large red flag to wave.
But then you apparently need to be shown that you are wrong. Audit trails
are great too, but watch out for the penetrated superuser interface.
(This comment only touches the tip of the iceberg. Judging from this
issue's contributions, I imagine the discussion might run for a while.
Let's get down to specific cases if we can, but not just students'
grades -- which are only an illustrative problem.) PGN]
------------------------------
Date: Wed, 9 Oct 85 11:36:54 EDT
From: Andy←Mondore%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
To: RISKS@SRI-CSL.ARPA
Subject: Databases, Grades, etc.
Hal Murray in RISKS-1.20 asks whether any schools are "brave/stupid enough"
to have students and grades on the same computer. Well, that is the
situation here. Administrators and students use the same mainframe.
Administrative here generally use several extra layers of security such as
extra passwords, allowing sign-ons to certain accounts only from specific
terminals, and logging all successful and unsuccessful sign-ons to our
accounts. So far, we in the Registrar's Office have not detected any
unauthorized sign-ons (and we have never noticed any strange changes to
files) although we occasionally detect an unsuccessful sign-on attempt from
an unauthorized location. Generally, changing passwords frequently and
using non-words and special characters for passwords seems to take care of
the unauthorized access problem.
One thing that Hal did not mention is security problems when students and
grades are on separate computers but on the same network, perhaps to share a
special device or certain files. It seems to me that there could be almost
as many potential security problems with this configuration as with my
configuration. Does anyone have experience with this type of configuration
and if so, what problems have you had?
------------------------------
Date: Wed 9 Oct 85 09:50:12-EDT
From: Mark S. Day <MDAY@MIT-XX.ARPA>
Subject: Databases, Grades, etc.
To: risks@SRI-CSL.ARPA
I tend to think that stories about crackers changing their grades should be
taken with a fairly large dose of salt.
I once had the occasion to interview a vice-chancellor at my undergraduate
university, and he explained the system there in some detail. Basically,
they handled grades the way a bank handles money -- that is to say, there
were 'audit trails' and paper copies of everything.
Discrepancies between what was in the computer and what was in the paper
records would eventually get caught, even if there was a period of time when
the wrong grades would show up on an official transcript. Correctly faking
ALL the records so as to escape an audit would have required a great deal of
knowledge (basically, it would have to be an inside job -- and they didn't
have students working in these offices).
--Mark
------------------------------
Date: Wed 9 Oct 85 11:39:54-PDT
From: Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Subject: Databases, Grades, etc.
To: MDAY@MIT-XX.ARPA
cc: Neumann@SRI-CSL.ARPA
Mark, I find myself disbelieving some of what you say. Manual comparisons
tend to get done (if at all) when the data is entered. Auditing tends to
get slighted, since people often tend to assume the computer is right! (The
Santa Clara inmate who changed his release date did get caught, but perhaps
only because a guard overheard him bragging about how he was going to get
out early.) Most vice-chancellors (and many administrators) would probably
tell you they are doing things right, and better than everyone else. That
is the head-in-the-sand view of computing -- everything is just fine. But
audit trails and paper copies of everything are not sufficient, even if they
are diligently used. "Discrepancies ... would eventually get caught" is
certainly hopeful, at best. Peter
------------------------------
Date: Wed 9 Oct 85 14:51:40-EDT
From: Mark S. Day <MDAY@MIT-XX.ARPA>
Subject: Databases, Grades, etc.
To: Neumann@SRI-CSL.ARPA
Peter,
I still maintain that the scenario of "student changes grades to A's and
lives happily ever after" seems dubious. It seems to be one of these
apocryphal stories where everyone knows about someone who's done it, but
there's little evidence floating around about it (sort of like stories about
people putting cats in microwave ovens to dry them).
Your other comments are well-taken. It certainly requires administrators,
etc., to have a perception of the problem; that was one reason I was
impressed by my interview with the vice-chancellor. Several years ago,
crackers were not yet in the public eye, so I was pleasantly surprised to
find out that anyone cared about the overall integrity of the grades
database and talked about the need to regularly audit it.
--Mark
------------------------------
Date: Wed, 9 Oct 85 12:40:43 cdt
From: Alan Wexelblat <wex@mcc.ARPA>
To: risks%sri-csl@mcc
Subject: Databases, Grades, etc.
The University I attended had its database on a computer that student
courses used. However, it was (is) a very well-kept secret. It is hard
(under the OS of this system) to find out what people *might* log on. Also,
it seems that hacker-types don't get the work-study jobs in the registrar's
office. I'm not sure how long they can keep it up, but it's worked well for
at least 5 years. (I only found out because I got to be good friends with
the facilities people, and one of them happened to mention it.)
I guess this just reinforces the belief that human beings can make a risky
or less-risky depending on how they use it. --Alan Wexelblat WEX@MCC.ARPA
------------------------------
Date: Wed, 09 Oct 85 16:12:15 EDT
From: Ross McKenrick <CRMCK%BROWNVM.BITNET@WISCVM.ARPA>
To: RISKS@SRI-CSL.ARPA
Subject: Databases, Grades, etc.
Students and grades can exist on the same machine. Attempting to partition
the students' and administrations' computing environments is a crude form of
security which eliminates the possibility of providing students online
services such as class lists and registration changes.
We take a two-fold approach to database security at Brown University:
1) prevention and 2) detection. We minimize our window of vulnerability
by making it nearly impossible to gain unauthorized access to the
programs which update grades, etc, and by making it nearly impossible
to change a grade (even when authorized) without generating audit
records, security log entries, and notifications slips for the professor.
We are not dealing with an EFT-type environment where "smash-and-grab" might
work. A student is at Brown for four years, and his/her transcript is
maintained by the Registrar forever. A student could theoretically change
his/her grade for a day or two *in the computer database* (which does not
mean that the grade, which is intangible, was actually changed). However, a
system of checks and balances, built into and outside of the computer
system, would eventually result in discovery, correction, and punishment.
Suppose I could design a security system which was 90% (OK, 80%) secure.
Then, rather than spend more time making it more secure (point of
diminishing returns), I could spend my time on a recording/ reporting system
which was 80% secure. Now, I finish by dovetailing the two systems to make
it very unlikely that a hacker could survive both levels. Meanwhile, the
Registrar, who is rightfully suspicious of computer security anyway, devises
manual checks and balances which adds another level of security beyond the
computer entirely.
Wouldn't it simply be easier for the hacker to forge a grade change slip
from his/her professor? Now, considering all of this, you've got certain
expulsion and prosecution under Rhode Island State Law hanging over your head.
Why would someone who's got all of this figured out have trouble passing
courses, anyway?
A collegue of mine likens a malicious hacker in a fairly-well-secured
computer environment to a bull in a china shop. The china is replaceable,
the bull is dead meat.
Now comes the auto-theft-prevention-device philosophy: why pick on
a fairly-well-secured environment when there are so many unsecured
environments to fool with?
Security in computer-recordkeeping is a very serious subject. But
you must keep it in perspective with the alternatives: manual record-
keeping, locked doors and desks, etc.
------------------------------
Date: Thu, 10 Oct 85 09:34 EDT
From: Randy Parker <PARKER@MIT-REAGAN.ARPA>
Subject: Databases, Grades, etc.
To: RISKS@SRI-CSL.ARPA
Regarding the subject of the risks of computer technology (in general)
and large databases (FBI's NCIC, TRW, NSA, tenant/landlord database in
California, and the Census), there is a reporter from the New York Times
who has done quite a bit of research into it. His name is David
Burnham, and his results a few years back are published in his book "The
Rise of the Computer State" (paper/hardback).
The book is a call to arms to the millions who don't realize the serious
threat to our freedom that this poses. Its shortcoming, as such, is
that it is mostly a quite comprehensive series of anecdotal reports on
various errors and abuses (incorrect warrants, Nixon abuse of phone
company records, abuse by politicians, etc) of large informations
stores. However, if you need convincing that this is a problem, you
will find it in this book.
Burnham spoke here this past Tuesday and updated his list of "horror
stories", as he puts it. One number he gave, if my notes are right, is
that an FBI audit of their NCIC showed that ~10% of the warrants proposed
by this system are somehow based on incomplete or invalid information.
He also mentioned proposals to increase the NCIC to include a White
Collar Crime Index that would specifically contain the names of SUPPOSED
white collar criminals and their ASSOCIATES. As Burnham pointed out, if
they can't maintain the actual criminal information properly, what are
the consequences when they start accumulating hearsay and gossip?
A serious problem is that no one has a real interest in keeping this
information very correct, except for the falsely accused citizen, and,
as Burnham pointed out, he doesn't have any way to correct it. I also
agree quite heartily with Matt Bishop that "the greatest risk is not
from the technological end but the human end." The technology itself is
not to blame, but we need, especially as computer professionals whose
opinions in the matter would be seriously regarded, to recognize the
growing threat to our liberties and to act accordingly.
Randy Parker
MIT AI Lab
PARKER@MIT-REAGAN
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂11-Oct-85 0804 BRESNAN@SU-CSLI.ARPA announcement of MSDI presentations
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 08:04:05 PDT
Date: Fri 11 Oct 85 07:59:49-PDT
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: announcement of MSDI presentations
To: folks@SU-CSLI.ARPA
cc: bresnan@SU-CSLI.ARPA
The working group on Morphology/Syntax/Discourse Interactions will
be giving a series of open presentations of the results of its
summer research project, which have been abstracted in the CSLI Newsletter.
On Thursday, October 24, at 10:00 a.m. in the Ventura Conference
Room. Joan Bresnan will present Bresnan and Mchombo's "Subject,
Topic, and Agreement in Chichewa". A written version of this
work will be available on Monday, October 21, at the Ventura
Receptionist's Desk.
-------
∂11-Oct-85 1315 PATASHNIK@SU-SUSHI.ARPA Speaker for October 17
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 13:15:03 PDT
Date: Fri 11 Oct 85 13:04:49-PDT
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: Speaker for October 17
To: aflb.all@SU-SUSHI.ARPA
We still have no speaker for October 17 (this coming week). Please
let me know if you want give a talk then.
--Oren
-------
∂11-Oct-85 1502 LIBRARY@SU-SCORE.ARPA Socrates: Workshops to be held in the Green Library
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 15:01:49 PDT
Date: Fri 11 Oct 85 14:58:36-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: Workshops to be held in the Green Library
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12150352299.8.LIBRARY@SU-SCORE.ARPA>
The Libraries will be offering instruction in the use of Socrates, the online
catalog, this Fall Quarter. Provided will be a brief overview of Socrates,
how to search in Guided mode, and most of the session will concentrate
on using Socrates in Command mode. Handson practice, using Macintosh
computers, will be available. The workshops will be limited in size,
and advance registration is recommended. Please register by calling the
General Reference Department at 497-1811 or at the Reference Desk in
Green Library.
Dates: Oct. 16 Wed. 3-5pm Oct. 23 Wed. 9-11 am Oct. 29 Tues. 9-11 am
Nov. 6 Wed. 3-5pm Nov. 12 Tues. 3-5pm Nov. 18 Mon 9-11 am
Nov. 25 Mon. 3-5 pm
Sessions will be held in the McDermott Room, Green Library
-------
∂11-Oct-85 2217 BRESNAN@SU-CSLI.ARPA presentation by Peter Sells
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 22:17:50 PDT
Date: Fri 11 Oct 85 22:15:10-PDT
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: presentation by Peter Sells
To: folks@SU-CSLI.ARPA
On October 17 Peter Sells will be giving a talk entitled "On the Notion
of `Logophoricity'" at CSLI. This presentation is also part of the
Morphology/Syntax/Discourse Interactions series of presentations I
announced previously, and a written version of the paper will be
available upon request from the author by Monday October 21.
-------
∂12-Oct-85 0800 PATASHNIK@SU-SUSHI.ARPA AFLB Abstract
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 12 Oct 85 08:00:48 PDT
Date: Sat 12 Oct 85 07:58:25-PDT
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: AFLB Abstract
To: aflb.all@SU-SUSHI.ARPA
We have a speaker for the upcoming AFLB. Here's the abstract:
17-Oct-85 : Richard Beigel (Stanford)
Sorting n objects with a k-sorter.
A k-sorter is an instruction (or black box or what-you-will) that
sorts k objects in constant time. An interesting question is ``How
quickly can you sort n objects with a k-sorter?'' We will demonstrate
asymptotic bounds of nlogn/klogk and 4nlogn/klogk. We will also show
how to sort in nlogn/(k-1) + O(1); this is of interest when k is small.
Finally we will discuss the particular case of sorting with a 3-sorter.
***** Time and place: October 17, 12:30 pm in MJ352 (Bldg. 460) ******
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352 (Bldg 460).
If you have a topic you would like to talk about in the AFLB seminar
please let me know. (Electronic mail: patashnik@su-sushi.arpa, phone:
(415) 497-1787). Contributions are wanted and welcome. Not all time
slots for this academic year have been filled.
For more information about future and past AFLB meetings and topics
are in the file [SUSHI]<patashnik.aflb>aflb.bboard .
- Oren Patashnik
-------
∂14-Oct-85 0755 @SUMEX-AIM.ARPA:HAUNGA@SU-SCORE.ARPA Title & Abstract for the Siglunch Friday 18th.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 14 Oct 85 07:55:46 PDT
Received: from SU-SCORE.ARPA by SUMEX-AIM.ARPA with TCP; Mon 14 Oct 85 07:55:48-PDT
Date: Mon 14 Oct 85 07:52:23-PDT
From: Ana Haunga <HAUNGA@SU-SCORE.ARPA>
Subject: Title & Abstract for the Siglunch Friday 18th.
To: SIGLUNCH@SUMEX-AIM.ARPA
cc: haunga@SU-SCORE.ARPA
Message-ID: <12151061140.11.HAUNGA@SU-SCORE.ARPA>
Siglunch will be held at the Chemistry Gazebo at 12:05-1:00 p.m.
-------
Title: Probabilistic Interpretations for MYCIN's Certainty Factors
Abstract:
I will show that the original definition of certainty factors (CF's)
is inconsistent with the "defining desiderata" of the CF combination
functions. I will then show that if this inconsistency is removed by
redefining CF's in terms of the desiderata then CF's have
probabilistic interpretations. In other words, I will show that
certainty factors are nothing more than transformed probabilistic
quantities. The construction of the interpretation provides insights
into the assumptions made when propagating CF's through an inference
net. For example, it can be shown that all evidence which bears
directly on a hypothesis must be conditionally independent on the
hypothesis and its negation. After presenting the interpretations,
I will discuss several ramifications of the correspondence between
CF's and probabilities.
-------
-------
∂14-Oct-85 0851 RICHARDSON@SU-SCORE.ARPA Tuesday CSD Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 14 Oct 85 08:51:11 PDT
Date: Mon 14 Oct 85 08:44:08-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Tuesday CSD Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12151070563.14.RICHARDSON@SU-SCORE.ARPA>
Tomorrow's lunch speaker and topic will be: Tom Wasow on "An Interdepartmental
Program in Symbolic Systems". MJH 146 at 12:15.
-------
∂14-Oct-85 0907 @SUMEX-AIM.ARPA:HAUNGA@SU-SCORE.ARPA SPEAKER for Friday 18th SIGLUNCH is David Heckerman.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 14 Oct 85 09:07:41 PDT
Received: from SU-SCORE.ARPA by SUMEX-AIM.ARPA with TCP; Mon 14 Oct 85 09:05:42-PDT
Date: Mon 14 Oct 85 09:02:13-PDT
From: Ana Haunga <HAUNGA@SU-SCORE.ARPA>
Subject: SPEAKER for Friday 18th SIGLUNCH is David Heckerman.
To: SIGLUNCH@SUMEX-AIM.ARPA
Message-ID: <12151073854.11.HAUNGA@SU-SCORE.ARPA>
Sorry for not mentioning it in the previous
message.
--a
-------
∂14-Oct-85 1231 CAROL@SU-CSLI.ARPA Phone number
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Oct 85 12:31:04 PDT
Date: Mon 14 Oct 85 12:27:21-PDT
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: Phone number
To: Folks@SU-CSLI.ARPA
cc: Carol@SU-CSLI.ARPA
Hi-
I have a new phone number here in Ventura 28: 321-2136. Don't
forget to dial 9.
-Carol
-------
∂14-Oct-85 1557 ACUFF@SUMEX-AIM.ARPA Explorer Update
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 14 Oct 85 15:57:50 PDT
Date: Mon 14 Oct 85 15:56:25-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Explorer Update
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12151149256.15.ACUFF@SUMEX-AIM.ARPA>
Folks -
Good News: We now have 10 MB (at least for a while) of memory in
our first Explorer.
Bad News: No new software or machines until next week (but both
should arrive then).
-- Rich
-------
∂14-Oct-85 1849 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #22
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 14 Oct 85 18:49:27 PDT
Date: 14 Oct 85 1820-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #22
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Tuesday, 15 Oct 1985 Volume 1 : Issue 22
Today's Topics:
Seminar: Randomized Routing on Fat-Trees (MIT)
Seminar: Connectionist Parallel Distributed Processing (UCB)
A reading list for "Connectionism and Parallel Dist. Proc."
----------------------------------------------------------------------
Date: 10/08/85 11:37:44
From: LISA at MIT-MC.ARPA
Re: R.L. Greenberg, "Randomized Routing on Fat-Trees"
[Forwarded by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
SEMINAR
DATE: Thursday, October 10, 1985
TIME: Lecture 2:00 p.m.
PLACE: NE43-512A
"RANDOMIZED ROUTING ON FAT-TREES"
Ronald L. Greenberg
M.I.T.
Laboratory for Computer Science
ABSTRACT
Fat-trees are a class of routing networks for hardware-efficient
parallel computation. This talk will present a randomized algorithm
for routing messages on a fat-tree. The qualiity of the algorithm is
measured in terms of the load factor of a set of messages to be
routed, which is a lower bound on the time required to deliver the
messages. We show that if a set of messages has load factor lambda =
omega (lg n lg lg n) on a fat-tree with n processors, the number of
delivery cycles (routing attempts) that the algorithm requires is
O(lambda) with probability 1 - O(1/n). The best previous bound was
O(lambda lg n) for the off-line problem where switch settings can be
determined in advance. In a VLSI-like model where hardware cost is
equated with physical volume, we use the routing algorithm to
demonstrate that fat-trees are universal routing networks in the sense
that any routing network can be efficiently simulated by a fat-tree of
comparable hardware cost. This is joint work with Charles Leiserson.
------------------------------
Date: Wed, 25 Sep 85 14:09:11 PDT
From: chertok%ucbcogsci at Berkeley.EDU (Paula Chertok)
To: AIList
Re: Seminar - Connectionist Parallel Distributed Processing (UCB)
[Forwarded from AIList by Steven A. Swernofsky <SASW@MIT-MC.ARPA>]
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar -- IDS 237A
TIME: Tuesday, October 1, 11:00 - 12:30
PLACE: 240 Bechtel Engineering Center
(followed by)
DISCUSSION: 12:30 - 1:30 in 200 Building T-4
SPEAKER: David Rumelhart, Institute for Cognitive
Science, UCSD
TITLE: ``Parallel Distributed Processing: Explora-
tions in the Microstructure of Cognition''
Parallel Distributed Processing (PDP) is the name which I and
my colleagues at San Diego have given to the class of
neurally-inspired models of cognition we have been studying.
We have applied this class of "connectionist" models to a
variety of domains including perception, memory, language
acquisition and motor control. I will briefly present a gen-
eral framework for the class of PDP models, show how these
models can be applied in the case of acquisiton of verb mor-
phology, and show how such macrostructural concepts as the
schema can be seen as emerging from the microstructure of PDP
models. Implications of the PDP perspective for our under-
standing of cognitive processes will be discussed.
------------------------------
Date: Fri, 11 Oct 85 15:01:57 est
From: "Marek W. Lugowski" <marek%indiana.csnet@CSNET-RELAY.ARPA>
Subject: A reading list for a "Connectionism and Parallel Dist. Proc."
Subject: course
[Long message, last in this digest. -- BD]
I posted the following to AIList@SRI-AI recently. PGS%OZ@MC suggests
that it might be of interest here. As I do not subscribe to PARSYM,
any replies ought to be made to MAREK@INDIANA.CSNET (or MAREK%OZ@MC,
same difference).
-- Marek
P.s. The proposed course is to be taught at Indiana University's CS
Dept. sometime within a year. It's meant for advanced graduate
students.
----------------
A list of sources for teaching a graduate AI course "Connectionism and
Parallel Distributed Processing" at Indiana University's Computer Science
Department. Compiled by Marek W. Lugowski (marek@indiana.csnet) and Pete
Sandon (sandon@wisc-ai.arpa), Summer 1985.
Ackley, D. H., "Learning Evaluation Functions in Stochastic Parallel
Networks," CMU Thesis Proposal, December 1984.
Amari, S-I., "Neural Theory of Association and Concept-Formation," Biological
Cybernetics, vol. 26, pp. 175-185, 1977.
Ballard, D. H., "Parameter Networks: Toward a Theory of Low-Level Vision,"
IJCAI, vol. 7, pp. 1068-1078, 1981.
Ballard, D. H. and D. Sabbah, "On Shapes," IJCAI, vol. 7, pp. 607-612, 1981.
Ballard, D. H., G. E. Hinton, and T. J. Sejnowski, "Parallel Visual
Computation," Nature, vol. 103, pp. 21-26, November 1983.
Ballard, D. H., "Cortical Connections: Structure and Function," University of
Rochester Technical Report #133, July 1984.
Block, H. D., "A Review of "Perceptrons: An Introduction to Computational
Geometry"," Information and Control, vol. 17, pp. 501-522, 1970.
Bobrowski, L., "Rules of Forming Receptive Fields of Formal Neurons During
Unsupervised Learning Processes," Biological Cybernetics, vol. 43,
pp. 23-28, 1982.
Bongard, M., "Pattern Recognition", Hayden Book Company (Spartan Books), 1970.
Brown, C. M., C. S. Ellis, J. A. Feldman, T. J. LeBlanc, and G. L. Peterson,
"Research with the Butterfly Multicomputer," Rochester Research Review,
pp. 3-23, 1984.
Christman, D. P., "Programming the Connection Machine," MIT EECS Department
Masters Thesis, 1984.
Csernai, L. P. and J. Zimanyi, "Mathematical Model for the Self-Organization
of Neural Networks," Biological Cybernetics, vol. 34, pp. 43-48, 1979.
Fahlman, S. E., NETL, a System for Representing and Using Real Knowledge ,
MIT Press, Cambridge, Massachusetts, 1979.
Fahlman, S. E., G. E. Hinton, and T. J. Sejnowski, "Massively Parallel
Architectures for AI: NETL, Thistle and Boltzmann Machines," Proceedings
of the National Conference on Artificial Intelligence, 1983.
Feldman, J. A., "A Distributed Information Processing Model of Visual Memory,"
University of Rochester Technical Report #52, December 1979.
Feldman, J. A., "Dynamic Connections in Neural Networks," Biological
Cybernetics, vol. 46, pp. 27-39, 1982.
Feldman, J. A. and D. H. Ballard, "Computing with Connections," in Human and
Machine Vision, ed. J. Beck, B. Hope and A. Rosenfeld (eds), Academic
Press, New York, 1983.
Feldman, J. A. and L. Shastri, "Evidential Inference in Activation Networks,"
Rochester Research Review, pp. 24-29, 1984.
Feldman, J. A., "Connectionist Models and Their Applications: Introduction,"
Special Issue of Cognitive Science, vol. 9, p. 1, 1985.
Fry, G., ed., Nanotechnology Notebook, an unpublished collection of published
and unpublished material on molecular computing. Contact either the
editor (cfry@mit-prep.arpa) or Scott Jones (saj@mit-prep.arpa) at MIT
Artificial Intelligence Laboratory for distribution and/or bibliography
information. Contains material by Eric Drexler, Richard Feynman, Kevin
Ulmer and others.
Fukushima, K., "Cognitron: A Self-organizing Multilayered Neural Network,"
Biological Cybernetics, vol. 20, pp. 121-136, 1975.
Fukushima, K., "Neocognitron: A Self-organizing Neural Network Model for
a Mechanism of Pattern Recognition Unaffected by Shift in Position,"
Biological Cybernetics, vol. 36, pp. 193-202, 1980.
Hebb, D. O., The Organization of Behavior, Wiley, New York, 1949.
Hewitt, C., "Viewing Control Structures as Patterns of Passing Messages",
Artificial Intelligence: An MIT Perspective, Winston and Brown, Editors,
MIT Press, Cambridge, Massachusetts, 1979.
Hewitt, C. and P. de Jong, "Open Systems", MIT Artificial Laboratory Memo #691,
December 1982.
Hewitt, C. and H. Lieberman, "Design Issues in Parallel Architectures for
Artificial Intelligence", MIT Artificial Intelligence Lab Memo #750,
November 1983.
Hewitt, C., an article on asynchronous parallel systems not simulable
by Turing Machines or Omega-order logic, BYTE, April 1985.
Hillis, D. W., "New Computer Architectures and Their Relationship to Physics
or Why Computer Science Is No Good", International Journal of
Theoretical Physics, vol. 21, pp. 255-262, 1982.
Hinton, G. E., "Relaxation and its Role in Vision," University of Edinburgh
Ph.D. Dissertation, 1977.
Hinton, G. E. and J. A. Anderson, Parallel Models of Associative Memory,
Lawrence Erlbaum Associates, Hillsdale, New Jersey, 1981.
Hinton, G. E. and T. J. Sejnowski, "Optimal Perceptual Inference," Proceedings
of the IEEE Computer Society Conference on CV and PR, pp. 448-453,
June 1983.
Hinton, G. E., T. J. Sejnowski, and D. H. Ackley, "Boltzmann Machines:
Constraint Satisfaction Networks that Learn," CMU Department of Computer
Science Technical Report No. 84-119, May 1984.
Hinton, G. E., "Distributed Representations", CMU Department of Computer
Science Technical Report No. 84-157, October 1984.
Hirai, Y., "A New Hypothesis for Synaptic Modification: An Interactive Process
between Postsynaptic Competition and Presynaptic Regulation," Biological
Cybernetics, vol. 36, pp. 41-50, 1980.
Hirai, Y., "A Learning Network Resolving Multiple Match in Associative
Memory," IJCPR, vol. 6, pp. 1049-1052, 1982.
Hofstadter, D. R., "Who Shoves Whom Inside the Careenium?, or, What is the
Meaning of the Word 'I'?", Indiana University Computer Science Department
Technical Report #130, Bloomington, Indiana, 1982.
Hofstadter, D, "The Architecture of Jumbo", Proceedings of the International
Machine Learning Workshop, Monticello, Illinois, June 1983.
Hofstadter, D. R., "The Copycat Project", MIT Artificial Intelligence Lab
Memo #755, Cambridge, Massachusetts, January 1984.
Hofstadter, D. R., Metamagical Themas, Basic Books, New York, 1985.
Hopfield, J.J., "Neural Networks and Physical Systems with Emergent Collective
Computational Abilities," Proceedings of the National Academy of
Sciences, vol. 79, pp. 2554-2558, 1982.
Jefferson, D. E., "Virtual Time", UCLA Department of Computer Science
Technical Report No. 83-213, Los Angeles, California, May 1983.
Jefferson, D. E. and H. Sowizral, "Fast Concurrent Simulation Using the Time
Warp Mechanim, Part 1: Local Control", Rand Corporation Technical Report,
Santa Monica, California, June 1983.
Jefferson, D. E. and H. Sowizral, "Fast Concurrent Simulation Using the Time
Warp Mechanim, Part 2: Global Control", Rand Corporation Technical Report,
Santa Monica, California, August 1983.
John, E. R., "Switchboard versus Statistical Theories of Learning and Memory,"
Science, vol. 177, pp. 850-864, September 1972.
Kandel, E. R., "Small Systems of Neurons," Scientific American, vol. 241,
pp. 67-76, September 1979.
Kanerva, P., Self-Propagating Search: A Unified Theory of Memory, Center
for Study of Language and Information (CSLI) Report No. 84-7 (Stanford
Department of Philosophy Ph.D. Dissertation), Stanford, California, 1984.
To appear as a book by Bradford Books (MIT Press).
Kanerva, P., "Parallel Structures in Human and Computer Memory", Cognitiva 85,
Paris, June 1985.
Kirkpatrick, S., and C. D. Gelatt, Jr. and M. P. Vecchi, "Optimization by
Simulated Annealing", Science, vol. 220, no. 4598, 13 May 1983.
Kohonen, T., "Self-Organized Formation of Topologically Correct Feature Maps,"
Biological Cybernetics, vol. 43, pp. 59-69, 1982.
Kohonen, T., "Analysis of a Simple Self-Organizing Process," Biological
Cybernetics, vol. 44, pp. 135-140, 1982.
Kohonen, T., "Clustering, Taxonomy, and Topological Maps of Patterns," IJCPR,
vol. 6, pp. 114-128, 1982.
Kohonen, T., Self-Organization and Associative Memory, 2nd edition,
Springer-Verlag, New York, 1984.
Lieberman, H., "A Preview of Act1", MIT Artificial Intelligence Lab Memo #626.
Malsburg, C. von der, "Self-Organization of Orientation Sensitive Cells in the
Striate Cortex," Kybernetik, vol. 14, pp. 85-100, 1973.
McClelland, J. L., "Putting Knowledge in its Place: A Scheme for Programming
Parallel Processing Structures on the Fly," Cognitive Science, vol. 9,
pp. 113-146, 1985.
McClelland, J. L. and D. E. Rumelhart, "Distributed Memory and the
Representation of General and Specific Information," Journal of
Experimental Psychology: General, vol. 114, pp. 159-188, 1985.
McClelland, J. L. and D. E. Rumelhart, Editors, Parallel Distributed
Processing: Explorations in the Microstructure of Cognition, Volume 1,
Bradford books (MIT Press), Cambridge, Massachusetts, 1985 (in press).
McCullough, W. S., Embodiments of Mind, MIT Press, Cambridge, Massachusetts,
1965.
Minsky, M. and S. Papert, Perceptrons: An Introduction to Computational
Geometry, MIT Press, Cambridge, Massachusetts, 1969.
Minsky, M., "Plain Talk about Neurodevelopmental Epitemology", MIT Artificial
Intelligence Lab Memo #430, June 1977.
Minsky, M., "K-Lines: A Theory of Memory", MIT Artificial Intelligence Lab
Memo #516, June 1979.
Minsky, M., "Nature Abhors an Empty Vaccum", MIT Artificial Intelligence Lab
Memo #647, August 8, 1981.
Mozer, M. C., "The Perception of Multiple Objects: A Parallel, Distributed
Processing Approach", UCSD Thesis Proposal, Institute for Cognitive
Science, UCSD, La Jolla, California, August 1984.
Nass, M. M. and L. N. Cooper, "A Theory for the Development of Feature
Detecting Cells in Visual Cortex," Biological Cybernetics, vol. 19,
pp. 1-18, 1975.
Norman, "Categorization of Action Slips", Psychological Review, vol. 88, no. 1,
1981.
Palm, G., "On Associative Memory," Biological Cybernetics, vol. 36, pp. 19-31,
1980.
Plaut, D. C., "Visual Recognition of Simple Objects by a Connection Network,"
University of Rochester Technical Report #143, August 1984.
Rosenblatt, F., Principles of Neurodynamics, Spartan Books, New York, 1962.
Rumelhart, D. E. and D. Zipser, "Feature Discovery by Competitive Learning,"
Cognitive Science, vol. 9, pp. 75-112, 1985.
Sabbah, D., "Design of a Highly Parallel Visual Recognition System," IJCAI,
vol. 7, pp. 722-727, 1981.
Sabbah, D., "Computing with Connections in Visual Recognition of Origami
Objects," Cognitive Science, vol. 9, pp. 25-50, 1985.
Smolensky, P., "Schema Selection and Stochastic Inference in Modular
Environments", Proceedings of the AAAI-83, Washington, 1983.
Theriault, D. G., "Issues in the Design and Implementation of Act2", MIT
Artificial Intelligence Lab Technical Report #728, June 1983.
Touretzky, D. S. and G. E. Hinton, "Symbols Among the Neurons: Details of
a Connectionist Inference Architecture," IJCAI, vol. 9, pp. 238-243,
1985.
Uhr, L., "Recognition Cones and Some Test Results," in Computer Vision
Systems, ed. A. R. Hanson and E. M. Riseman, Academic Press, New York,
1978.
Uhr, L. and R. Douglass, "A Parallel-Serial Recognition Cone System for
Perception: Some Test Results," Pattern Recognition, vol. 11, pp. 29-39,
1979.
Van Lehn, K., "A Critique of the Connectionist Hypothesis that Recognition
Uses Templates, not Rules," Proceedings of the Sixth Annual Conference
of the Cognitive Science Society, 1984.
Willshaw, D. J., "A Simple Network Capable of Inductive Generalization,"
Proceedings of the Royal Society of London, vol. 182, pp. 233-247, 1972.
----------------
A list of contacts known to us that have taught or are interested in
teaching a similar course/seminar:
J. Barnden, Indiana U. Computer Science
G. Hinton, CMU Computer Science
D. Hofstadter, U. of Michigan Psychology
J. McClelland, CMU Psychology
D. Rumelhart, UCSD Psychology
P. Smolensky, U. of Colorado Computer Science
D. Touretzky, CMU Computer Science
------------------------------
End of PARSYM Digest
********************
∂15-Oct-85 0820 DAVIES@SUMEX-AIM.ARPA Meeting at 9:30 Wednesday
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 08:20:22 PDT
Date: Tue, 15 Oct 1985 08:21 PDT
Message-ID: <DAVIES.12151328649.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: Meeting at 9:30 Wednesday
cc: Davies@SUMEX-AIM.ARPA
Harold Brown will report on last week's DARPA Strategic Computing
meeting.
∂15-Oct-85 0829 RICHARDSON@SU-SCORE.ARPA Tuesday Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 08:29:29 PDT
Date: Tue 15 Oct 85 08:27:29-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Tuesday Lunch Series
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12151329676.15.RICHARDSON@SU-SCORE.ARPA>
Don't forget -- lunch today in MJH 146 at 12:15!
-------
∂15-Oct-85 0932 ullman@su-aimvax.arpa meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 09:32:32 PDT
Received: by su-aimvax.arpa with Sendmail; Tue, 15 Oct 85 09:29:22 pdt
Date: Tue, 15 Oct 85 09:29:22 pdt
From: Jeff Ullman <ullman@diablo>
Subject: meeting
To: nail@diablo
We'll meet at 11AM tomorrow.
There is, as usual, no agenda.
I'll try to suggest some open problems, and perhaps others
can suggest their favorites as well.
By the way: the following was returned to me;
perhaps someone wants to look at it:
S Kunifuji and H. Yokuta, "Plorog and relational databases for
fifth generation computer systems."
∂15-Oct-85 1103 RICHARDSON@SU-SCORE.ARPA Tuesday CSD Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 11:03:35 PDT
Date: Tue 15 Oct 85 11:01:16-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Tuesday CSD Lunch Series
To: faculty@SU-SCORE.ARPA
Message-ID: <12151357670.15.RICHARDSON@SU-SCORE.ARPA>
Nils will not be available for the CSD Tuesday Lunch Series on November 5
and on November 19. Is there anyone out there that has a favorite lunch
topic and is willing to lead a discussion on same for either of these dates?
Anne
-------
∂22-Oct-85 1545 BARWISE@SU-CSLI.ARPA Logic Lunch
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 15:42:25 PDT
Date: Sun 20 Oct 85 14:32:39-PDT
From: Jon Barwise <BARWISE@SU-CSLI.ARPA>
Subject: Logic Lunch
To: Folks@SU-CSLI.ARPA
Reminder: Logic lunch moves to the philosophy lounge tomorrow, Monday,
at noon.
-------
∂22-Oct-85 1828 HANRAHAN@SU-SCORE.ARPA petty cash
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 17:22:04 PDT
Date: Tue 22 Oct 85 10:37:01-PDT
From: Katherine Hanrahan <HANRAHAN@SU-SCORE.ARPA>
Subject: petty cash
To: csd@SU-SCORE.ARPA
Stanford-Phone: (415) 497-2273
Message-ID: <12153188264.32.HANRAHAN@SU-SCORE.ARPA>
Sorry for the inconvenience (once again) but there will be no petty cash
until friday afternoon. Katie
-------
∂22-Oct-85 1859 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar on Logic and the Foundations of Mathematics
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 18:57:35 PDT
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 22 Oct 85 18:53:00-PDT
Date: 22 Oct 85 1722 PDT
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: Seminar on Logic and the Foundations of Mathematics
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
Speaker: Dag Westerstahl, CSLI
Title: Branching generalized quantifiers
Time: Friday, Oct. 25, Noon to 1:15
Place: Room 383N (faculty lounge, 3d floor, Math. Bldg.).
S. Feferman
NB. This will be our regular time from now on, every other week.
∂22-Oct-85 1908 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #43
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 15:48:00 PDT
Date: Monday, October 21, 1985 6:53PM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #43
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Tuesday, 22 Oct 1985 Volume 3 : Issue 43
Today's Topics:
LP Philosophy - Hewitt's Challenge,
Implementation - Destructive Assignment,
Announcement - Third ICLP,
Puzzles - Games & Fun
----------------------------------------------------------------------
Date: Thu, 17 Oct 85 16:46:21 bst
From: William Clocksin <wfc%computer-lab.cambridge.ac.uk@ucl-cs>
Subject: Lisp in Prolog
One of Carl Hewitt's recent comments concerns writing a Lisp
system in Prolog. It has subsequently been argued by
contributors that Hewitt's comments are irrelevant to Prolog
as a foundation for AI (whatever "foundation" means anyway).
I agree with them, but setting that aside for a moment, it
cannot have escaped the attention of most people that writing
a compiler (in Prolog) to COMPILE Lisp into some target (say LAP)
would be as easy as pie. For those of us who have written
compilers in both Lisp and Prolog, I daresay it would be a lot
easier in Prolog. I might further suggest that the compiler
test is more useful than the interpreter test, and that the
interpreter test has no especial theoretical advantage, since
the compiler can be seen as a meaning-preserving transformation.
(Ahem. Which in fact it isn't for Lisp if you're not careful
with bindings).
------------------------------
Date: 9 Oct 85 12:56 PDT
From: Kahn.pa@Xerox.ARPA
Subject: Destructive assignment
First I would like to comment on Paul Hudak discussion on mutable
arrays and elaborate on an earlier point by Fernando.
A couple years ago I implemented mutable arrays in LM-Prolog. The
idea is that an update predicate have arguments for both the old and
new version of the array being changed. The semantics of the
predicate was given as a straight-forward but expensive simulation
of arrays using lists and updates using copying. The implementation
was, of course, free to represent the versions of the array in any
way that maintained the semantics of the predicate.
The most common representation was a perfectly ordinary array for
the most recent version and for the old version a data structure
representing the old values for component that have changed and
pointer to the newest version. The details of all this can be
found in the paper by Lars-Henrik Eriksson and Manny Rayner in the
proceedings of the Second International Logic Programming Conference
held in Uppsala Sweden 1984. As Paul points out that when the old
version is not referenced after the update that a compiler can
optimize even that overhead away.
Concurrent Prolog has an even more direct way of programming as if
one had destructive assignment by relying on tail recursion
optimization. But both schemes and the one that Fernando talked about
earlier have one deficiency/ackwardness. Namely, a "pointer" to a
mutable data structure does not see any changes since they continue to
point the old version. As Fernando points out to get around this one
needs to start at the top of any system of data structures. In
Concurrent Prolog one avoids this problem in a different ackward
manner -- every time in a conventional program with side effects that
one "passes out" pointers one needs to explictly call "merge" to split
the references.
------------------------------
Date: 9 Oct 85 12:56 PDT
From: Kahn.pa@Xerox.ARPA
Subject: Prolog vs Lisp
Apropos the long debate started by Carl Hewitt:
As co-author of LM-Prolog, the best performing Prolog
implemented in Lisp, I thought some performance numbers
might be useful. Naive reverse runs at 10K Lips on a
CADR Lisp Machine with special micro-code support,
primarily for unification and trailing. Without any
micro-code support it runs 2 to 3 times slower. While
there are much faster Prologs available, I would argue
that LM-Prolog is commerically viable without the
micro-code. There have been sales of the 3600 version
of LM-Prolog despite the fact that it is not supported
by micro-code.
But part of Fernando's counter to Carl was that a serious
Prolog implementation needs sub-primitives that Lisp does
not provide. It is true that LM-Prolog even without micro
-code relies on Zeta-Lisp's sub-primitives to manipulate
pointers and create invisible pointers. This makes
de-referencing variables very fast. While I don't have
any figures I don't think that is so important, at least
for the naive reverse benchmark. In other words I believe
a pure Common Lisp implementation of Prolog on say a 3600
would run 3 or 4 times slower than Symbolics Prolog (which
is fully micro-coded). Depending upon how important a
factor of 3 or 4 is, one evaluates differently Carl's claim
that Lisp is good for implementing Prolog (and not vice
versa).
I think part of this whole debate is confused with the larger
debate of single paradigm vs multi-paradigm languages. My
feeling is that while a single paradigm system is elegant that
too often it doesn't fit the problem well and ackward cliches
are used. For example, it is widely believed that for some
kinds of problems object-oriented programming is most
appropriate because it encasulates state and behavior so well.
Concurrent Prolog advocates in such situations program objects
in a complex cliche of tail recursive predicates where one
argument is a stream of messages. No serious object-oriented
language requires that each method list all the instance variables
in the head and their new values again at the end of each "method"
(the tail recursive call). I am not happy with the argument that
goes -- well some problems are best programmed with Lisp, others
with Prolog, others with SmallTalk, and still others with OPS5.
Any significantly large problem is going to have sub-problems
that are best handled by different paradigms.
The debate should not be Lisp vs. Prolog but how can we combine
Lisp and Prolog (and Smalltalk and ...) in a coherent well
-integrated fashion. Its not easy. LM-Prolog was one attempt at
doing this, as well as ICOT's ESP, Prolog-KR and LogLisp. I
tried to integrate Prolog with Loops. None of these integrations
are perfect but I think this is the direction to go for BUILDING
TOOLS for BUILDING REAL APPLICATIONS. The CommonLoops effort at
Xerox represents to me the best effort to date to build a tight
integration of two paradigms (object and procedure-oriented).
In contrast, to what I just said I think the single paradigm
approach can be a great research strategy. Much of the Logic
Programming community is caught up in the game of finding out
how far can one go with logic programming. Can one write
simulators, text editors, graphics, operating systems, embedded
languages, and so on in Prolog or a language like it? It is
rightfully considered cheating to "escape to Lisp" or jump into
some object-oriented sub-system. Their purpose is to explore
the paradigm itself -- its uses, its limitations, to stretch it
and pull it in new directions not to build real applications.
When building real applications the question is not can this or
that be done in Prolog, we all know that everything can be written
in Prolog, but what language can give the best support for building
the application in the most fitting way.
------------------------------
Date: Fri, 18 Oct 85 17:35:28 -0200
From: Ehud Shapiro <udi%wisdom.bitnet@WISCVM>
Subject: Third ICLP - a reminder
In case you have forgot, or in case you didn't read the Digest
over the summer, the deadline for papers to the Third International
Conference on Logic Programming is December 1st, 1985.
I enclose again the call for papers, since the previos message
suffered from several minor mistakes.
Regards,
-- Ehud Shapiro
P.S. If you have been a referee for the previous Conference or
for the previous Sumposia, please expect to receive a few papers
for refereeing for the winter vacation... We will not ask
explicit permission to send them, but just send them to you and
hope for the best (i.e. for your cooperation...)
CALL FOR PAPERS
Third International Conference on Logic Programming
Imperial College of Science and Technology, London, UK
July 14-18, 1986
In cooperation with:
Association for Computing Machinery
British Computer Society
Japan Society for Software Science and Technology
The conference will consider all aspects of logic programming,
including, but not limited to:
Theory and foundations
Architectures and Implementations
Methodology
Programming Languages and Environments
Applications
Relations to other computation models, programming
languages, and programming methodologies.
Of special interest are papers related to parallel processing,
papers discussing novel applications and applications that address
the unique character of logic programming, and papers which
constitute a contribution to computer science at large.
Papers can be submitted under two categories, short --
up to 2000 words, and long -- up to 6000 words. Submissions will
be considered on the basis of appropriateness, clarity, originality,
significance, and overall quality.
Authors should send eight copies of their manuscript, plus an
extra copy of the abstract, to:
Ehud Shapiro
ICLP Program Chairman
The Weizmann Institute of Science
Rehovot 76100, Israel.
Deadline for submission of papers is December 1, 1985.
Authors will be notified of acceptance or rejection
by February 28, 1986.
Camera ready copies are due April 1st, 1986.
Keith Clark
General Chairman
Imperial College of Science and Technology
180 Queen's Gate
London SW7 2BZ, United Kingdom
Local Arrangements and Exhibition Chairman
Richard Ennals
Imperial College of Science and Technology
180 Queen's Gate
London SW7 2BZ, United Kingdom
Program Committee
Michel van Caneghem, University of Marseille, France
Keith Clark, Imperial College, UK
Veronica Dahl, Simon Fraser University, Canada
Maarten van Emden, University of Waterloo, Canada
Kazuhiro Fuchi, ICOT, Japan
Koichi Furukawa, ICOT, Japan
Ake Hansson, Uppsala University, Sweden
Kenneth M. Kahn, Xerox PARC, USA
Peter Koves, Logicware Inc., Canada
Giorgio Levi, University of Pisa, Italy
John Lloyd, University of Melbourne, Australia
Frank G. McCabe, Imperial College, UK
Jack Minker, Maryland University, USA
Fernando Pereira, SRI International, USA
Antonio Porto, University of Lisbon, Portugal
Ehud Shapiro, Chairman, Weizmann Institute, Israel
------------------------------
Date: Fri, 11-Oct-85 06:11:56 PDT
From: Joe Armstrong <mcvax!enea!erix!joe@Seismo>
Subject: An exciting game in PROLOG
# unpacked will be owned by you and have default permissions.)
#
# This archive contains:
# READ←ME game.pl
echo x - READ←ME
cat > "READ←ME" << '//E*O*F READ←ME//'
A THRILLING GAME IN PROLOG WITH HIGH SPEED HIGH RESOLUTION VT100
GRAPHICS.
This program is donated to the public domain and may be used,
modified re-distributed, or simply throw away as seen fit by the
user.
With this program I hope to fill a 'gap' in the market - I have
often seen requests for "really badly written banal games written
in FORTRAN" - since PROLOG has been described as the FORTRAN of
logic programming I hope this program fills that gap.
I make no apologies for the code, though I suspect that purests
may object to the "(cut,...,fail);true" constructs that are
liberally sprinkled throughout the program.
Plans are underway to write yet more thrilling, exciting,
spectacular, addictive, brilliant, wonderful, enchanting games in
SASL, HOPE, PARLOG, ML, etc.
-- Joe Armstrong.
//E*O*F READ←ME//
echo x - game.pl
cat > "game.pl" << '//E*O*F game.pl//'
/*------------------------------------------------------------*/
/* to run this program: enter prolog and type ['game.pl'],go. */
/*------------------------------------------------------------*/
go :-
noscroll,
system('stty cbreak',←),
start,!,
play.
play :-
putat(24,1,"type space to spin the chamber"),
get0(←),
putat(24,1," "),
random(6,N),
move(24,60),put("you spun "),write(N),
possibly←die(N),
play.
possibly←die(6) :- die.
possibly←die(N).
putat(X,Y,Text) :- move(X,Y),put(Text).
start :-
cls,print←thing←at(2,5,gun),print←thing←at(1,60,head).
die :-
put(7),
print←thing←at(11,20,bang),
un←print←thing←at(11,20,bang),
move←thing←at(2,39,30),
print←thing←at(2,69,bullit),
print←thing←at(11,20,aagh),
un←print←thing←at(11,20,aagh),
un←print←thing←at(1,60,head),
cls,
system('echo "your game got played" | mail joe@erix.UUCP',←),
putat(24,1,"like to dice (sic) with death again (y/n):"),
get0(X),
possibly←doit←again(X).
possibly←doit←again(121) :- start,!,play.
possibly←doit←again(110) :- abort.
move←thing←at(X,Y,N) :-
(for(I,1,N),
Y1 is Y + I -1,
print←thing←at(X,Y1,bullit),
un←print←thing←at(X,Y1,bullit),
fail);true.
un←print←thing←at(X,Y,Z) :- un←print←thing←at←1(X,Y,Z);true.
un←print←thing←at←1(X1,Y,Z) :-
F =.. [Z,N,L],!,
call(F),
X is X1 + N - 1,
move(X,Y),
undraw(L),nl,fail.
undraw(L) :-
(length(L,M),!,for(I,1,M),put(32),fail);true.
print←thing←at(X,Y,Z) :- print←thing←at←1(X,Y,Z);true.
print←thing←at←1(X1,Y,Z) :-
F =.. [Z,N,L],!,
call(F),
X is X1 + N - 1,
move(X,Y),
put(L),nl,fail.
for(I,I,Upper).
for(I,Lower,Upper) :-
Lower < Upper,
Next is Lower + 1,
for(I,Next,Upper).
move(X,Y) :- printf("%c%c%d%c%d%c",[27,91,X,59,Y,72]).
scroll(X,Y) :- printf("%c%c%d%c%d%c",[27,91,X,59,Y,114]),move(24,1).
noscroll :- scroll(1,24).
cls :- printf("%c%c%c%c",[27,91,50,74]).
seed(13).
random(R,N) :-
retract(seed(S)),
N is (S mod R) +1,
NewSeed is (125*S+1) mod 4096,
asserta(seed(NewSeed)),!.
gun(1, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx").
gun(2, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx").
gun(3, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx").
gun(4, "xxxxxxxxxxxxxxxxxxxxxxxxx").
gun(5, "xxxxxxxxxxxxx x x").
gun(6, "xxxxxxxxxxxxx x x").
gun(7, "xxxxxxxxxxxxx x x").
gun(8, "xxxxxxxxxxxxxxxxx").
gun(9, "xxxxxxxxxxx").
gun(10,"xxxxxxxxxxx").
gun(11,"xxxxxxx").
gun(12,"xxxxxxx").
gun(13,"xxxxxxx").
gun(14,"xxxxxxx").
gun(15,"xxxxxxx").
gun(16,"xxxxxxx").
head(1, " xxxxxxxxx").
head(2, " xxxxxxxxxxxx").
head(3, " xx xxx").
head(4, " x xxxxxxx").
head(5, " x xxx xxxxxx").
head(6, " x xxxxx x xxx").
head(7, " x xxxx xx xx").
head(8, " x xx x x").
head(9, " x xx x x").
head(10," x x x x").
head(11," x x").
head(12," x x").
head(13,"x x").
head(14,"x x").
head(15,"xxxxx x").
head(16," xx x").
head(17," xxx x").
head(18," xx xxx x").
head(19," xxxx x x").
head(20," x x").
head(21," x x").
bullit(1,"==>").
bullit(2,"===>").
bullit(3,"==>").
bang(1, "xxxx xx x x xxx ").
bang(2, "x x x x xx x x x ").
bang(3, "x x x x x x x x x ").
bang(4, "xxx xxxxxx x x x x ").
bang(5, "x x x x x x x x xxx").
bang(6, "x x x x x xx x x ").
bang(7, "xxxx x x x x xx ").
aagh(1, " xx xx xxx x x").
aagh(2, " x x x x x x x x").
aagh(3, "x x x x x x x x").
aagh(4, "xxxxxx xxxxxx x xxxxxx").
aagh(5, "x x x x x xxx x x").
aagh(6, "x x x x x x x x").
aagh(7, "x x x x xx x x").
//E*O*F game.pl//
exit 0
------------------------------
End of PROLOG Digest
********************
∂22-Oct-85 1911 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 18:24:36 PDT
Date: Tue 22 Oct 85 10:26:57-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12153186430.20.RICHARDSON@SU-SCORE.ARPA>
Lunch today --- MJH 146 at 12:15
-------
∂22-Oct-85 1915 ullman@su-aimvax.arpa meeting this week
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 15:52:35 PDT
Received: by su-aimvax.arpa with Sendmail; Mon, 21 Oct 85 10:52:35 pdt
Date: Mon, 21 Oct 85 10:52:35 pdt
From: Jeff Ullman <ullman@diablo>
Subject: meeting this week
To: nail@diablo
This week we actually have a speaker.
Richard Treitel is going to speak about conjuct ordering.
The meeting will begin at TEN AM, in 301 MJH,
as both Richard and I have to leave before noon.
PS: You all have interesting things to speak about;
I know. So a volunteer or too would be appreciated.
---Jeff
∂22-Oct-85 1916 SELLS@SU-CSLI.ARPA Hinrichs dissertation
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 16:00:45 PDT
Date: Mon 21 Oct 85 15:15:21-PDT
From: Peter Sells <Sells@SU-CSLI.ARPA>
Subject: Hinrichs dissertation
To: folks@SU-CSLI.ARPA
If anybody's interested, I have received a copy of Erhard Hinrich's
dissertation "A Compositional Semantics for Aktionsarten and NP Reference in
English", and will willingly lend it for viewing or copying.
Peter
-------
∂22-Oct-85 1919 BRESNAN@SU-CSLI.ARPA "Topic, Pronoun, and Agreement in Chichewa"
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 15:53:43 PDT
Date: Mon 21 Oct 85 11:26:19-PDT
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: "Topic, Pronoun, and Agreement in Chichewa"
To: folks@SU-CSLI.ARPA
This is the title of the presentation to be given this Thursday
(Oct. 24) at 10:00 at the Ventura Conference Room at CSLI by Joan
Bresnan. A written version of this work by Bresnan and Mchombo
is now available at the receptionist's desk at CSLI.
-------
∂22-Oct-85 1919 LIBRARY@SU-SCORE.ARPA Math/CS Library: Electronic Services--If New To Stanford Please Read
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 18:40:34 PDT
Date: Tue 22 Oct 85 17:16:44-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library: Electronic Services--If New To Stanford Please Read
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12153261031.9.LIBRARY@SU-SCORE.ARPA>
The Math/CS Library offers some services through electronic messaging. Our
address is Library@SCORE. We announce new technical reports and new books
on the bulletin boards. When we announce new material they are usually
on display in the library for a week to two weeks. If you would like to
be placed on a waiting list to see the material after it is off of display,
send us a message and include the item you would like to see (accession
number or call number, author, and title) and your name, electronic address,
and physical address.
You may also renew books electronically. If you have a reference question,
send that to us and we will get back to you with the answer or advice on
how to approach the problem.
When using the Math/CS Library electronically, please attempt to send
us as much information as you have. Please be as precise and concise
as you can. Always include your name, physical address, and electronic
address. If you make a request that doesn't require an answer back,
don't expact a response back from us such as ok etc. If there is
some problem with your request (such as you want to renew a book and
someone else is waiting for it) we will get back to you. When
we have electronic mailing addresses we will recall materials from
you with an electronic message. If you find a citation in Socrates
that would probably be in the Math/CS Library but you are referred
to a HELP STATUS screen, you could send the record to me and we
will make sure we place you on a list to be notified when received.
I hope you will find some of these services helpful to you while at
Stanford.
Harry Llull
-------
∂22-Oct-85 1921 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ernie.Berkeley.EDU
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 16:04:38 PDT
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Sat 19 Oct 85 16:06:40-PDT
Received: from UCB-VAX by SU-SCORE.ARPA with TCP; Sat 19 Oct 85 16:06:16-PDT
Received: by UCB-VAX (5.28/5.13)
id AA06342; Sat, 19 Oct 85 15:58:29 PDT
Received: by ernie (5.28/5.13)
id AA02466; Sat, 19 Oct 85 15:57:59 PDT
Date: Sat, 19 Oct 85 15:57:59 PDT
From: karp@ernie.Berkeley.EDU (Richard Karp)
Message-Id: <8510192257.AA02466@ernie>
To: Theory-b@ernie.Berkeley.EDU, aflb.all@su-score.arpa,
allmsgs@ernie.Berkeley.EDU, csfac@ernie.Berkeley.EDU,
theory@ernie.Berkeley.EDU
SEMINAR ANNOUNCEMENTS
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley (415)-548-6843
Tuesday, October 29 2:00 MSRI Lecture Hall
Steven Fortune "Sweepline Algorithms for Voronoi Diagrams"
Tuesday, October 29 4:00 MSRI Lecture Hall
Ketan Mulmuley "Computing the Rank of a Matrix Over an Arbitrary Field is
in NC(2)
∂22-Oct-85 1923 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #24
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 16:11:01 PDT
Date: 21 Oct 85 2121-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #24
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Tuesday, 22 Oct 1985 Volume 1 : Issue 24
Today's Topics:
Second PARSYM Survey -- Data Abstractions (continued)
----------------------------------------------------------------------
Date: Sun 20 Oct 85 21:28:15-EDT
From: vijay <Vijay.Saraswat@C.CS.CMU.EDU>
Subject: PARSYM Digest second survey.
Let me take this opportunity to respond to the PARSYM Survey on data
abstractions. I cannot resist, particularly after Bert Halstead's post
on MULTILISP (PARSYM Digest V1 #20). The remarks I will make are
generally applicable to the spectrum of concurrent logic programming
languages (Concurrent Prolog, Guarded Horn Clauses, Parlog,
Delta-Prolog), but I will make them in the context of the language
CP[!,|,&,;] on which I have been working. (I assume familiarity with
the basic notions of logic programming.)
1. Are you using or have you developed data structures or
abstractions specialized for parallel computing? Please
describe.
Most CLP languages are based on the notion of pattern-matching via
unification. In these languages the (logical) variable X stands for
some fixed but possibly unknown object. As computation proceeds,
several processes can cooperate to construct a value for this object.
By the very nature of unification, (almost) ALL operations in these
languages can happen even if the variable does not have a binding.
(Remember that as far as operation on data is concerned, there is ONLY
ONE primitive in these languages -modulo details- and that is
unification: this primitive is used for parameter passing/"value
return", "assignment", data-structure construction/selection etc.)
Most CLP languages, however, provide for mechanisms that allow the
user to restrict the bidirectionality of unification: CP[!,|,&] does
it by the notion of the wait-annotation (!). This annotation can
decorate occurrences of terms (variables/constants/structured terms)
ONLY in the head of a clause. Whenever a goal is unified against the
head of a clause, then !-unification succeeds iff all !-decorated
terms in the head of the clause unify against non-variables; otherwise
!-unification may suspend or fail. (!-unification fails iff (normal)
unification fails.)
For example, given the clause "+(A,0!,A)." !-unification of
--the goal "+(X,Y,2)" will SUSPEND,
--the goal "+(X,0,Y)" will SUCCEED with X unifying against Y,
--the goal "+(X,2,Y)" will FAIL.
The "future" construct that Halstead describes seems to be capturing
precisely the behaviour of the logical variable. The logic
programming paradigm already has (the equivalent of) that construct
built-in. On the other hand, CLP languages must specify extra-logic
control annotations to allow a programmer to specify (in the
terminology of Halstead) "strict operators". For instance here is the
definition of "strict car":
car([A | Rest]!, A).
Note:
-- "the value returned by car" -A- may itself be unknown (i.e. a
"future")... if it is desired to wait for A to be instantiated as
well, one needs the axiom "car([A! | Rest]!, A!)." instead.
-- if the ! was removed from the axiom, the resultant axiom would have
allowed the CREATION of a list whose car was A, rather than waiting
for the list to be instantiated.
To give another example, here is the definition of a "strict plus",
which assumes the presence of an is/2 arithmetic predicate.
+(X!,Y!,Z):- Z is X+Y.
+(X!,Y,Z!):- Y is Z-X.
+(X,Y!,Z!):- X is Z-Y.
+(X,0!,X).
+(0!,X,X).
2. In particular, do you use specialized data abstractions to
represent configurations of multiple processes? Please
describe.
Again, the use of the logical variable allows the programmer to create
very versatile configurations of processes. In fact the basic
programming technique that Shapiro's Concurrent Prolog supports well
is the creation of process structures which exactly mimic the
data-structures in a more conventional sequential algorithm.
Specifically, with other collaborators, he has published literally
dozens of algorithms which use the pipeline structure that Halstead
mentions, along with other such exotic structures as "pyramidal
computers", H-trees, aleph trees, quad trees etc.
I have personally been exploring using unification to achieve
algorithms with "surprising" complexity: e.g. Danny Dolev et al's
"Lord of the Rings" problem (computing the maxima in a ring of
processes) can be solved in O(n) unifications (as contrasted with
O(n log n) messages in his algorithm)... the trick is that unification
allows you to dynamically reduce the size of the ring at practically
no cost.
CP[!,|] (which is identical to Concurrent Prolog but for the '!' which
is simpler, and cleaner than Concurrent Prolog's '?') also naturally
supports data-flow programming in general and the soft-systolic
paradigm in particular.
CP[!,&,;], which has AND-concurrency and OR-sequentiality (;), is also
the natural framework for the computational paradigm of constraints.
This paradigm is characterised by collections of processes with
provisions for `distributed backtracking'. Unlike Guy Steele's
system, however, it is also possible to describe algebraic
transformations of the constraint network in a CP[!,&,;]-like
language.
3. Do you use specialized data structures, a la FRONS, for
representing non-deterministic collections of data? Please
describe.
With Larry Rudolph I have been exploring the use of ACId
data-structures, i.e. the free algebra built from a binary constructor
f/2 which is associative, commutative and idempotent for nil (i.e.
f(nil,nil)=nil). As is well known these equations can be built into
the unifier engine. One fallout is that two terms may now have more
than one most general unifiers. This allows a very powerful
`non-determinstic' way to provide random (`associative') access to the
multi-set data-structure. In fact, in conjunction with
AND-concurrency and the wait (!) control annotation this allows the
facile simulation of shared-memory (PRAM-like) architectures in the
CLP framework.
This data-structure is quite powerful when used in conjunction with
the don't know commit [&] in CP[!,|,&] which allows the pursuit of
disjoint disjunctive paths by processes.
4. What are some useful references on the topic of data abstraction
in parallel computing (including your own)?
More information on the language CP[!,|,&] can be obtained from my
paper on `Partial correctness semantics for CP[!,|,&]' which is to be
presented at the Fifth Conference on Foundations of Software
Tech. and Theo. Comp. Sci., New Delhi Dec 1985 and by to-be-out-soon
tech rep on `An operational semantics for CP[!,|,&]'. The primary reference
on Concurrent Prolog remains the paper `A subset of Concurrent Prolog
and its interpreter', Weizmann Instt. tech rep, 1983. An
algorithm-oriented reference is `Systolic programming: a pardigm for
parallel processing' by Shapiro in FGCS 84. A paper on
Parlog is to appear soon in TOPLAS. None of these papers explicitly
discuss the topic of data-abstraction.
Vijay Saraswat.
------------------------------
End of PARSYM Digest
********************
∂22-Oct-85 2055 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 18:50:11 PDT
Date: Mon 21 Oct 85 08:16:10-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch Series
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12152900478.19.RICHARDSON@SU-SCORE.ARPA>
Tomorrow, Oct. 22, the Tuesday Lunch series will continue with Dean Eustis
on the subject of "The Role of Personal Computers in Courses and Labs" in
MJH 146 at 12:15.
-------
∂22-Oct-85 2056 RICHARDSON@SU-SCORE.ARPA [The Mailer Daemon <Mailer@SU-SCORE.ARPA>: Message of 17-Oct-85 10:40:56]
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 18:53:08 PDT
Date: Mon 21 Oct 85 08:52:45-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: [The Mailer Daemon <Mailer@SU-SCORE.ARPA>: Message of 17-Oct-85 10:40:56]
To: Tob@SU-AI.ARPA, rwf@SU-AI.ARPA, dek@SU-AI.ARPA, zm@SU-AI.ARPA,
jmc-lists@SU-AI.ARPA, tw@SU-AI.ARPA
Message-ID: <12152907140.19.RICHARDSON@SU-SCORE.ARPA>
Date: Sun 20 Oct 85 10:56:22-PDT
From: The Mailer Daemon <Mailer@SU-SCORE.ARPA>
To: RICHARDSON@SU-SCORE.ARPA
Subject: Message of 17-Oct-85 10:40:56
Message undeliverable and dequeued after 3 days:
Tob@SU-AI.ARPA.#Internet: Cannot connect to host
rwf@SU-AI.ARPA.#Internet: Cannot connect to host
dek@SU-AI.ARPA.#Internet: Cannot connect to host
zm@SU-AI.ARPA.#Internet: Cannot connect to host
jmc-lists@SU-AI.ARPA.#Internet: Cannot connect to host
tw@SU-AI.ARPA.#Internet: Cannot connect to host
------------
Date: Thu 17 Oct 85 10:40:55-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Sr. Faculty Meeting in November
To: tenured@SU-SCORE.ARPA
Message-ID: <12151878255.11.RICHARDSON@SU-SCORE.ARPA>
Please let me know if you have any agenda item proposals for the November
Sr. Faculty Meeting.
Thanks,
Anne
-------
-------
-------
∂22-Oct-85 2058 @SU-SCORE.ARPA:WINOGRAD@SU-CSLI.ARPA Postponement of PhD program meeting
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Oct 85 18:57:44 PDT
Received: from SU-CSLI.ARPA ([36.9.0.46].#Internet) by SU-SCORE.ARPA with TCP; Mon 21 Oct 85 11:39:31-PDT
Date: Mon 21 Oct 85 11:35:41-PDT
From: Terry Winograd <WINOGRAD@SU-CSLI.ARPA>
Subject: Postponement of PhD program meeting
To: su-bboards@SU-CSLI.ARPA, phd@SU-SCORE.ARPA, faculty@SU-SCORE.ARPA,
phd-program@SU-SCORE.ARPA
cc: cheadle@SU-SCORE.ARPA
Many of the theory students an faculty will be going to the FOCS meeting
tomorrow and would like to participate. So it will be at the same time next
week (same place unless another announcment is made) i.e., 2:15 on Tuesday.
--t
-------
∂23-Oct-85 0609 PATASHNIK@SU-SUSHI.ARPA AFLB abstracts
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 06:09:00 PDT
Date: Wed 23 Oct 85 06:10:16-PDT
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: AFLB abstracts
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12153401849.9.PATASHNIK@SU-SUSHI.ARPA>
Here are the abstracts for the next two AFLBs.
*************************************
24-Oct-85 : Victor Pan (SUNY Albany)
Improved processor bounds for algebraic and combinatorial problems in RNC
Our two main results improve the processor bounds of two important problems:
Problem 1: Computing the exact inverse and determinant of an n by n matrix
whose entries are L-bit integers, L=n↑O(1).
Problem 2: Finding a perfect matching in a general graph.
The improved solutions maintain the best running time (O(log↑2 n),
O(log↑3 n), resp.) for the two problems. A solution to Problem 1 is
used in a number of parallel algorithms for algebraic problems as well
as solving Problem 2. A solution for Problem 2 is used in parallel
algorithms for several combinatorial problems. Consequently, the new
algorithms lead to improved solutions to several algebraic and
combinatorial problems.
***** Time and place: October 24, 12:30 pm in MJ352 (Bldg. 460) ******
31-Oct-85 : Steven Fortune (ATT Bell Labs)
Sweepline Algorithms for Voronoi Diagrams
We present a simple, sweepline algorithm for computing Voronoi
diagrams. The algorithm is applicable to Voronoi diagrams arising
from a set of points, a set of line segments, and a set of weighted
points. In all cases it achieves an O(n log n) worst-case time bound,
and a linear space bound. The algorithm is easy to implement, since
it avoids the merge step required by divide-and-conquer algorithms.
An application to a version of the piano mover's problem will also be
discussed.
***** Time and place: October 31, 12:30 pm in MJ352 (Bldg. 460) ******
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352.
If you have a topic you would like to talk about in the AFLB seminar
please let me know. (Electronic mail: patashnik@su-sushi.arpa, phone:
(415) 497-1787). Contributions are wanted and welcome. Not all time
slots for this academic year have been filled.
More information about future and past AFLB meetings and topics are in
the file [SUSHI]<patashnik.aflb>aflb.bboard .
- Oren Patashnik
-------
∂23-Oct-85 0749 @SU-CSLI.ARPA:RPERRAULT@SRI-AI.ARPA Talk by Bill Rounds
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 07:49:50 PDT
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Wed 23 Oct 85 07:45:02-PDT
Date: Wed 23 Oct 85 07:47:54-PDT
From: Ray Perrault <RPERRAULT@SRI-AI.ARPA>
Subject: Talk by Bill Rounds
To: friends@SU-CSLI.ARPA, aic-staff@SRI-AI.ARPA
cc: rperrault@SRI-AI.ARPA
SEMINAR ANNOUNCEMENT REMINDER
LOGIC AND LANGUAGE: CHARACTERIZING THE
COMPLEXITY OF LOGIC GRAMMARS
William C. Rounds
University of Michigan
4 p.m., Wednesday October 23, 1985
SRI International, Conference Room EJ228 (Bldg. E)
Modern artificial intelligence has seen the introduction of logic
as a tool for describing the syntax and semantics of natural language
grammars. In this talk I introduce two new notations for expressing
grammars, called CLFP and ILFP. These notations extend the first order
theory of concatenation and integer arithmetic with a Least Fixed
Point operator to accommodate recursive definitions of predicates. The
notations can be thought of as variants of definite clause grammars.
They are extremely easy to write and to understand. I prove that a
language is definable in CLFP if and only if it is recognizable by a
Turing machine in exponential time, and definable in ILFP if and only
if it is recognizable in polynomial time. As an application, I show
how to express head grammars in ILFP, thereby proving that head
languages are recognizable in polynomial time in a particularly easy
way.
-------
∂23-Oct-85 1048 CONTRERAS@SU-SCORE.ARPA Class Lists
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 10:47:57 PDT
Date: Wed 23 Oct 85 10:38:35-PDT
From: Tina Contreras <CONTRERAS@SU-SCORE.ARPA>
Subject: Class Lists
To: Instructors@SU-SCORE.ARPA
Message-ID: <12153450693.24.CONTRERAS@SU-SCORE.ARPA>
Your class lists are available here at the reception desk in MJH.
Tina
-------
∂23-Oct-85 1103 MODICA@SU-SCORE.ARPA Class Lists - Correction
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 11:03:18 PDT
Date: Wed 23 Oct 85 10:47:34-PDT
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: Class Lists - Correction
To: instructors@SU-SCORE.ARPA
Message-ID: <12153452330.46.MODICA@SU-SCORE.ARPA>
Please disregard previous message about Class Lists. Class Lists will be
available in MJH Rm. 251 today.
Gina
-------
∂23-Oct-85 1133 CONTRERAS@SU-SCORE.ARPA Mailboxes
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 11:33:52 PDT
Date: Wed 23 Oct 85 11:27:52-PDT
From: Tina Contreras <CONTRERAS@SU-SCORE.ARPA>
Subject: Mailboxes
To: Faculty@SU-SCORE.ARPA
cc: Staff@SU-SCORE.ARPA
Message-ID: <12153459665.24.CONTRERAS@SU-SCORE.ARPA>
Faculty and Staff mailboxes are going to be rearranged in alphabetical order.
Thank-You
Tina Contreras
Receptionist
-------
∂23-Oct-85 1303 YAMARONE@SU-CSLI.ARPA R/B + swiss Available Now at Front Desk
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 13:03:11 PDT
Date: Wed 23 Oct 85 12:57:51-PDT
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: R/B + swiss Available Now at Front Desk
To: folks@SU-CSLI.ARPA
Hungry yet?
3.25 will buy you a scrumptious sandwich ....a roast beef + swiss
on a french roll with all the acutraments!!
Come on now...don't hesitate, or it'll be too late.
-------
∂23-Oct-85 1432 ullman@su-aimvax.arpa financial detail
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 14:31:26 PDT
Received: by su-aimvax.arpa with Sendmail; Wed, 23 Oct 85 14:29:27 pdt
Date: Wed, 23 Oct 85 14:29:27 pdt
From: Jeff Ullman <ullman@diablo>
Subject: financial detail
To: nail@diablo
I may have been misconstrued at the meeting today.
Concerning Dave Smith's conjecture that the optimal ordering
of two sets of independent conjuncts is a merger of the
optimal orderings of the two sets, what I said was that
I would bet $1 that it was false (in particular because the
presence of a second set of conjuncts turns the problem
of optimally ordering the first set into finding a weighted
optimal ordering).
I did NOT say I would pay $1 to anyone solving the problem.
If you wish to take the bet, you have to be willing to
lose $1 if anyone comes up with a counterexample.
---Jeff
∂23-Oct-85 1611 admin@cogsci.Berkeley.EDU UCB Cognitive Science Seminar--Oct. 29, 1985
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 23 Oct 85 16:11:10 PDT
Received: by UCB-VAX (5.29/5.13)
id AA20261; Wed, 23 Oct 85 13:51:07 PDT
Received: by cogsci (5.29/5.13)
id AA07435; Wed, 23 Oct 85 13:52:25 PDT
Date: Wed, 23 Oct 85 13:52:25 PDT
From: admin@cogsci.Berkeley.EDU (Cognitive Science Program)
Message-Id: <8510232052.AA07435@cogsci>
To: allmsgs@cogsci.Berkeley.EDU, cogsci-friends@cogsci.Berkeley.EDU
Subject: UCB Cognitive Science Seminar--Oct. 29, 1985
Cc: admin@cogsci.Berkeley.EDU
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar - IDS 237A
Tuesday, October 29, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``Person Schemata''
Mardi J. Horowitz M.D.
Professor of Psychiatry, U.C.S.F.
The speaker directs the recently formed Program on Cons-
cious and Unconscious Processes of the John and Catherine T.
MacArthur Foundation. Research on person schemata is one of
the core agendas of this program.
After a brief description of the program, the discussion
will focus on clinical phenomena as segmented by different
states of mind in a single individual. By examining the confi-
guration in each state of mind as it occurs over time, it may
be possible to infer what the self schemata and role relation-
ship models are that organize thoughts, feelings and action
into observed patterns. The theory that forms the basis for
such inferences includes the postulate that each person's
overall self organization may include a partially nested
hierarchy of multiple self-concepts. A frequent set of states
of mind in pathological grief reactions will provide a concrete
illustration of phenomena, methods of inference, and a theory
of person schemata.
---------------------------------------------------------------------
UPCOMING TALKS
November 5: Edward Zalta, CSLI, Stanford
November 12: Robert Wilensky, Computer Science, UCB
November 19: Richard Alterman, Computer Science, UCB
November 26: Eve Clark, Linguistics, Stanford
December 3: Bernard Baars, Langley Porter, UCSF
---------------------------------------------------------------------
ELSEWHERE ON CAMPUS
John Dalbey, SESAME student, will present ``The Totally Effort-
less Problem Solver'' at the SESAME Colloquium on Monday,
October 28, 4:00pm, 2515 Tolman Hall.
Tom Wickens, U.C.L.A., will speak on ``Response Interactions in
Visual Detections'' at the Cognitive Psychology Colloquium,
Friday, November 1, 4:00pm, Beach Room, 3105 Tolman Hall.
∂23-Oct-85 1633 @SU-CSLI.ARPA:admin@cogsci.Berkeley.EDU UCB Cognitive Science Seminar--Oct. 29, 1985
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 16:31:57 PDT
Received: from UCB-VAX by SU-CSLI.ARPA with TCP; Wed 23 Oct 85 16:30:24-PDT
Received: by UCB-VAX (5.29/5.13)
id AA20261; Wed, 23 Oct 85 13:51:07 PDT
Received: by cogsci (5.29/5.13)
id AA07435; Wed, 23 Oct 85 13:52:25 PDT
Date: Wed, 23 Oct 85 13:52:25 PDT
From: admin@cogsci.Berkeley.EDU (Cognitive Science Program)
Message-Id: <8510232052.AA07435@cogsci>
To: allmsgs@cogsci.Berkeley.EDU, cogsci-friends@cogsci.Berkeley.EDU
Subject: UCB Cognitive Science Seminar--Oct. 29, 1985
Cc: admin@cogsci.Berkeley.EDU
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar - IDS 237A
Tuesday, October 29, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``Person Schemata''
Mardi J. Horowitz M.D.
Professor of Psychiatry, U.C.S.F.
The speaker directs the recently formed Program on Cons-
cious and Unconscious Processes of the John and Catherine T.
MacArthur Foundation. Research on person schemata is one of
the core agendas of this program.
After a brief description of the program, the discussion
will focus on clinical phenomena as segmented by different
states of mind in a single individual. By examining the confi-
guration in each state of mind as it occurs over time, it may
be possible to infer what the self schemata and role relation-
ship models are that organize thoughts, feelings and action
into observed patterns. The theory that forms the basis for
such inferences includes the postulate that each person's
overall self organization may include a partially nested
hierarchy of multiple self-concepts. A frequent set of states
of mind in pathological grief reactions will provide a concrete
illustration of phenomena, methods of inference, and a theory
of person schemata.
---------------------------------------------------------------------
UPCOMING TALKS
November 5: Edward Zalta, CSLI, Stanford
November 12: Robert Wilensky, Computer Science, UCB
November 19: Richard Alterman, Computer Science, UCB
November 26: Eve Clark, Linguistics, Stanford
December 3: Bernard Baars, Langley Porter, UCSF
---------------------------------------------------------------------
ELSEWHERE ON CAMPUS
John Dalbey, SESAME student, will present ``The Totally Effort-
less Problem Solver'' at the SESAME Colloquium on Monday,
October 28, 4:00pm, 2515 Tolman Hall.
Tom Wickens, U.C.L.A., will speak on ``Response Interactions in
Visual Detections'' at the Cognitive Psychology Colloquium,
Friday, November 1, 4:00pm, Beach Room, 3105 Tolman Hall.
∂23-Oct-85 1733 EMMA@SU-CSLI.ARPA Newsletter October 24, No. 51
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 17:33:25 PDT
Date: Wed 23 Oct 85 16:56:02-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter October 24, No. 51
To: friends@SU-CSLI.ARPA
Tel: 497-3479
!
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
October 24, 1985 Stanford Vol. 2, No. 51
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, October 24, 1985
12 noon TINLunch
Ventura Hall ``A Problem for Actualism About Possible Worlds''
Conference Room by Alan McMichael
Discussion led by Edward Zalta
2:15 p.m. CSLI Seminar
Redwood Hall Discourse, Intention, and Action
Room G-19 Two talks given by Phil Cohen and Amichai Kronfeld
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, October 31, 1985
12 noon TINLunch
Ventura Hall The Formation of Adjectival Passives
Conference Room by B. Levin and M. Rappaport
Discussion led by Mark Gawron
(Abstract on page 2)
2:15 p.m. CSLI Seminar
Redwood Hall Foundations of Document Preparation
Room G-19 David Levy, CSLI and Xerox PARC
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Redwood Hall The Structure of Social Facts
Room G-19 Prof. John Searle, Dept. of Philosophy, UC Berkeley
←←←←←←←←←←←←
CORRECTION
The coordinator for the Situation Theory and Situation Semantics
(STASS) project is Jon Barwise not David Israel as stated in last
week's newsletter.
!
Page 2 CSLI Newsletter October 24, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ABSTRACT OF NEXT WEEK'S TINLUNCH
The Formation of Adjectival Passives
B. Levin and M. Rappaport
This is Working Paper #2 in the MIT Lexicon Project, and though it
discusses some rather specific issues having to do with one (putative)
lexical rule of adjectival passive formation, it is an interesting
example of the lexicon at work in a GB-style theory, worked out in
unusual detail. It assumes no knowledge of the Lexicon Group's work
and only a minimal knowledge of GB.
Since Wasow 1977 it has been standard among generative grammarians
to assume two separate passivization rules, one for verbal passives,
another for adjectival passives. Levin and Rappaport argue against
the claim in Wasow 1980 that the second of these rules has a thematic
condition and propose an analysis of their own in which many of the
standardly-cited facts about adjectival passives fall out simply from
stipulating which arguments of a lexical item must be realized, and
assuming that such lexical facts are in the default case preserved in
the output of lexical rules. We thus have another case in which
thematic roles appear NOT to play the part they were claimed to play
in a specific morphological or syntactic process. Paradoxically,
although the paper is set in a framework which assumes specific
thematic roles, it presents an important negative result and casts
further doubt on the hypothesis that thematic roles play a significant
part in mediating the relation between syntax and lexical semantics.
--Mark Gawron
←←←←←←←←←←←←
NEXT WEEK'S CSLI SEMINAR
Foundations of Document Preparation
Document preparation, by which I mean the use of the computer to
prepare graphical presentations of verbal and pictorial information on
screens and on paper, is inherently a linguistic activity. This
statement is true in two senses: Documents, first of all, are
linguistic artifacts. But in addition, the use of the computer as a
marking tool is inherently linguistic: we *describe* to the computer
the documents we wish to create.
Current document preparation tools (the likes of TeX, Tedit, Emacs,
Scribe, etc.) are highly inadequate and unnecessarily restrictive.
This is because, I would claim, their designers have failed to take
explicit account of the linguistic nature of document preparation:
these tools have been built in advance of a theory of their subject
matter. In this talk, I will present an overview of research aimed at
developing a ``theory of marking'' to serve as the foundation for the
design of such tools. I will set forth the broad outlines of the
theory---one that lies at the intersection of a theory of production,
a theory of representation, and a theory of marks---and will
demonstrate that the issues of representation, reference, and action
with which the Center is concerned are central to this research. The
bulk of the talk will be devoted to illustrating the search for
founding concepts in the theory of marks---concepts such as figure,
ground, region, and blueprint. Such concepts are just as essential to
a future linguistics of written forms as to a foundation for document
preparation. --David Levy
!
Page 3 CSLI Newsletter October 24, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ENVIRONMENTS GROUP MEETING
The Rational Programming Environment - Summary
Wolfgang Polak, Kestrel
October 28, 1985, Ventura Trailer Classroom
In 1981 Rational commenced work on an Ada oriented software
development system. The goal was to create a commercial system
providing Lisp-style interactiveness and environment features for Ada.
The project encompassed a language oriented machine architecture,
specialized hardware, an integrated language based operating system
and programming environment, and project management support tools.
The original design used Ada's packages to create a hierarchy of
nested structures corresponding to conventional directory systems.
Permanent storage was provided by implementing persistent data objects
in the language. Programs and data are simply declarations within the
hierarchy of packages. Programs are only stored in internal
representation; semantic consistency (according to language semantics)
is maintained across the whole system. This organization allows
powerful program manipulation and query tools to be implemented
easily.
While very uniform, the use of packages as directories with the
associated semantic complexities proved cumbersome. In later versions
the directory structure was simplified and no longer subject to the
exact language rules.
The system is built around a powerful action mechanism. Any number
of directory/object manipulations can be associated with an action.
The action can later be committed, in which case all operations take
effect, or the action can be abandoned, in which case all operations
are undone.
The user interacts with the system via a multi-window editor. Each
window is of a particular type (e.g. text, program, status, etc.). The
system includes a general structure oriented editor which combines
structure operations with arbitrary text manipulation. Editor commands
are uniform across all windows; only the effect of structure
operations depends on the type of window.
Fast incremental compilation facilitates both interactive program
development and command execution.
----------
PIXELS AND PREDICATES
``Visual Programming Languages --
From Visual Assembler to Rocky's Boots''
Warren Robinett, with an assist by Scott Kim
CSLI trailers, Wednesday, October 30, 1:00 p.m.
A general view of the visual programming language problem is
presented, anchored by two concrete examples.
The first example is a visual assembly language, where patterns of
pixels are interpreted as low-level instructions which manipulate
patterns of pixels (and wherein one of the PnP themes is exemplified:
a very primitive `predicate made from pixels').
The second example is Rocky's Boots, a high-level visual
programming language based on the building circuits metaphor
(construed in some circles as an educational game).
!
Page 4 CSLI Newsletter October 24, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
SUMMARY OF ENVIRONMENTS GROUP MEETING
October 21, 1985
Terry Winograd described research on an environment for use by
people who are developing and modifying languages, and need to be able
to produce and manipulate texts in those languages during this
evolutionary phase. It is based on a uniform way of treating grammars
(based on a hierarchical phylum/operator structure with attributes),
so that structure editing, structured storage and other facilities
that are based on the language structure can be easily created and
developed.
He raised a number of issues that come up in trying to make the
environment general (for at least a broad class of existing and
envisioned languages), display-oriented (allowing dynamic changes of
structure and view), incremental (dealing well with continual small
updates), and distributed (multiple users cooperating in a
heterogeneous not-totally-reliable networked environment).
The current system is fragmentary and has not been integrated or
written up. Future talks by others in the group working on it will
address some of the more specific technical issues.
----------
CSLI SEMINAR SUMMARY
Ontology and Intensionality
Summary of CSLI Seminar on October 10
In this seminar, I outlined two recent developments in the theory
of abstract objects---one concerning ontology (the theory of times)
and one concerning intensionality (a solution to the Morning
Star/Evening Star puzzle). Moments of time were identified as
abstract objects, and truth at a time was defined in terms of the
encoding relation. Such definitions yielded the following non-trivial
consequences: times are maximal and consistent with respect to the
propositions true at them; there is a unique present time; a
proposition is always true iff it is true at all times, every
tense-theoretic consequence of a proposition true at a time is also
true at that time. In the second half of the seminar, we demonstrated
that once one uses structured entities as the denotations of
sentences, modal and tense contexts are not, in and of themselves,
intensional. Intensionality arises when definite descriptions appear
in such contexts, and by assigning definite descriptions a second
``intensional'' reading, on which they denote the abstract object
which encodes the properties they imply, we get a solution to the
substitutivity puzzles which preserves our intuitions about the
logical form of the sentences involved. --Edward N. Zalta
!
Page 5 CSLI Newsletter October 24, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
SITUATED ENGINE COMPANY
The STASS project has initiated a working group on the relation
between situation theory and computation. The aim is two fold: learn
what needs to be added to situation theory to enable it to give
adequate accounts of various computational agents, and to learn how we
might be able to use computers in doing situation theory. These two
aims cause us to distinguish between sigma-machines and tau-machines.
Sigma-machines are machines that are the subject matter for a
situation-theoretic analysis. Tau-machines are machines built to help
do situation theory.
In the long run, we expect that sigma and tau machines will merged,
that our theory machines will also be our subject matter machines.
For now, though, we are operating on two fronts simultaneously. A
simple robot, Gullible, has been designed and implemented by Brian
Smith, Mike Dixon and Tayloe Stansbury. It moves around on a grid,
meeting people, picking up information (and misinformation) and
answering certain questions about other people's locations based on
what it has experienced on its travels. This is to serve as our first
sigma-machine. Four groups have been formed to come up with
semantical analysis of this robot using situation theory.
On the other front, Jon Barwise has been lecturing about situation
theory and its logic, to give a feeling for the basic theory, raising
questions about what it might be reasonable to ask a computer to do,
and coming up with some vague ideas about how one might get it to do
it.
The group meets every Tuesday at Xerox PARC, at 2 p.m., for about
two hours. --Jon Barwise
---------
POSTDOCTORAL FELLOWSHIPS
The Center for the Study of Language and Information (CSLI) at
Stanford University is currently accepting applications for a small
number of one year postdoctoral fellowships commencing September 1,
1986. The awards are intended for people who have received their
Ph.D. degrees since June 1983.
Postdoctoral fellows will participate in an integrated program of
basic research on situated language---language as used by agents
situated in the world to exchange, store, and process information,
including both natural and computer languages.
For more information about CSLI's research programs and details of
postdoctoral fellowship appointments, write to:
Dr. Elizabeth Macken, Assistant Director
Center for the Study of Language and Information
Ventura Hall
Stanford University
Stanford, California 94305
APPLICATION DEADLINE: FEBRUARY 15, 1986
-------
∂24-Oct-85 0110 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #25
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 01:10:26 PDT
Date: 24 Oct 85 0108-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #25
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Thursday, 24 Oct 1985 Volume 1 : Issue 25
Today's Topics:
Parallel Logic Programming at Maryland
----------------------------------------------------------------------
Date: Wed, 23 Oct 85 15:04:10 EDT
From: Jack Minker <minker@mimsy.umd.edu>
Subject: Parallel Logic Programming at Maryland
AI and Database Research Laboratory
at the
University of Maryland
Jack Minker - Director
The AI and Database Research Laboratory at the Univer-
sity of Maryland consists of Jack Minker, the director of
the laboratory, and a number of faculty and students engaged
in diverse activities. One of the primary activities of
this group involves research into parallel problem solving,
with emphasis on distributed logic programming.
The AIDBRL members are developing a logic programming
system for the ZMOB multiprocessor, termed PRISM (parallel
inference system). The work started in earnest in approxi-
mately 1982. PRISM has been implemented and is being tested
on a simulated system. The underlying ideas behind PRISM
appeared in [Eisinger et. al., 1982] and [Kasif et. al.,
1983].
PRISM consists of several parts: a user host interface
that exists on the host machine; a set of Z80A machines
(moblets) designated as problem solvers (PSMs); a set of
machines designated as Extensional Database Machines (EDB)
that store ground atomic formulae (relational database
tables); and, a set of machines designated as Intensional
Database Machines (IDB) that store procedures (the general
rules in the system). The system can also optionally
include Constraint Machines (CM) that use user-supplied con-
straints to prune unsatisfiable paths in the proof tree.
The system supports both AND and OR parallelism. The
user can specify control in terms of the sequence of atoms
to be executed in a set of problems to be solved. Atoms can
be executed in parallel, sequentially, or as specified by a
partial ordering. Similarly procedures can be specified as
being executed sequentially, in parallel, or as specified by
a partial order. The PSM has been written in a modular
fashion to permit alternative control structure programs to
be incorporated in the system. Alternative node and literal
selection algorithms may be incorporated as part of the con-
trol structure. The user may specify the configuration
(i.e., the number of moblets required as a minimum) in which
a problem is to be run. If additional moblets are avail-
able, the PRISM will automatically take advantage of them.
A large number of problems are currently being pro-
grammed in PRISM and experiments will be run with these to
determine the effectiveness of PRISM as a problem solving
system.
The major research directions in the laboratory over
the coming year will be devoted to the following areas:
(1) Experimentation Using PRISM
(2) Control Structure Investigations
(3) Expert systems and PRISM
(4) Parallel problem solving and Architecture Issues
If you would like further information on PRISM, please
contact MINKER@MIMSY.UMD.EDU or MADHUR@MIMSY.UMD.EDU We
would also be very interested in hearing from people who may
have problems we could run on PRISM.
References:
1. Eisinger, N., Kasif, S., and Minker, J., "Logic Pro-
gramming: A Parallel Approach", in Proceedings of the
First International Logic Programming Conference, Mar-
seilles, France, 1982.
2. Kasif, S., Kohli, M., and Minker, J., "PRISM - A Paral-
lel Inference System for Problem Solving", in IJCAI-83,
Karlsruhe, Germany, 1983.
------------------------------
End of PARSYM Digest
********************
∂24-Oct-85 0819 EMMA@SU-CSLI.ARPA Today's CSLI seminar
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 08:19:37 PDT
Date: Thu 24 Oct 85 08:20:04-PDT
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Today's CSLI seminar
To: friends@SU-CSLI.ARPA
Tel: 497-3479
The titles of the two talks to be given by Phil Cohen and Ami Kronfeld
in today's 2:15 seminar are
Speech Acts and Rationality
Phil Cohen
The Referential/Attributive Distinction
Ami Kronfeld
As usual, the abstracts can be found in last week's newsletter.
-------
∂24-Oct-85 0847 AAAI-OFFICE@SUMEX-AIM.ARPA New Tutorial Chair
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 08:47:03 PDT
Date: Thu 24 Oct 85 08:45:05-PDT
From: AAAI <AAAI-OFFICE@SUMEX-AIM.ARPA>
Subject: New Tutorial Chair
To: officers: ;
cc: aaai-OFFICE@SUMEX-AIM.ARPA
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12153692175.16.AAAI-OFFICE@SUMEX-AIM.ARPA>
Mark Stefik has agreed to be next year's Tutorial Chair. The
Executive Council, by affirmative majority vote, needs to approve
his appointment. So we will need your vote as soon as possible
to commence our preparations for next year.
Regards,
Claudia
_
-------
∂24-Oct-85 1436 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 14:35:56 PDT
Date: Thu 24 Oct 85 14:36:39-PDT
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12153756177.24.LIBRARY@SU-SCORE.ARPA>
Parallel MIMD Computation: The HEP supercomputer and Its Applications.
ed. by J. S. Kowalik. MIT Press. QA76.8.D436P37 1985
Tutorial On Software Maintenance. by Girish Parikh and Nicholas Zveginitzov.
IEEE Computer Society. QA76.9.S65T87 1983.
Workshop On Distributed Computing. University of Newcastle Upon Tyne.
Computing Lab. S. K. Shrivastava. (8508666)
Real-Time Clinical Computing by Ian Perry. R853.D37P46 1984
Principles of Database Design. Volume 1 Logical Organizations. edited by
S. Bing Yao. QA76.9D3p73 1985 V. 1.
IEEE Standard Microcomputer System Bus. IEEE Std. 796-1983.
TK7895.B87158 1983.
Data Communicatons Software Design. by Malcolm Lane. TK5105.L357 1985.
Directory Of Statistical Microcomputer Software. 1985 Edition. by
Woodward, Elliott, and Gray. (8512454)
Stoyan, Herbert. Maschinen-unabhangige Code-Erzeugung als Semantikerhaltende
Beweisbare Programmtransformation. (8512466)
Computability With Pascal by Mallozzi and DeLillo. QA9.59.M34 1984.
A Design For Microprocessor-Based Systems. by Peels (8513505)
Data Structures With Ada. by Michael Feldman. Reston Publishing Co.
QA76.73.A35F45 1985.
Advanced UCSD Pascal Programming Techniques. by Willner and Demchak.
QA76.73.U25W55 1985.
The 3-D Animated Apple by Phil Cohen. T385.C543 1983.
Harry Llull
-------
∂24-Oct-85 1514 ullman@su-aimvax.arpa Dave Smith's conjecture
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 15:14:02 PDT
Received: by su-aimvax.arpa with Sendmail; Thu, 24 Oct 85 15:10:36 pdt
Date: Thu, 24 Oct 85 15:10:36 pdt
From: Jeff Ullman <ullman@diablo>
Subject: Dave Smith's conjecture
To: de2smith@sumex, genesereth@sumex, nail@diablo
Perhaps I should formulate my view of Dave Smith's conjecture
more carefully, to avoid having to pay out that dollar
needlessly.
My understanding of the model is that we wish to compute the
join of several database relations over a universal set of
attributes (i.e., the variables of the conjuncts).
We are given a cost function C(R1,...,Rk; R), that gives
the cost of joining the relation R with the already-computed
join of R1,...,Rk.
The problem is to minimize the sum
m
SIGMA C(S1,...,S{i-1}; Si)
i=1
over all permutations S1,...,Sm of the m given relations.
First, note that the input size in general is exponential in m,
making it unlikely that the problem is NP-complete, despite the
reference to my book in support of that claim.
However, there are restricted models, where the cost function C
can be encoded in some succinct way.
The simplest of these is one where there is a value n(R)
associated with each relation R, and C(R1,...,Rk; R) is
just the product of n(R1)*...*n(Rk)*n(R).
This case is too simple, and it is easy to pick an optimal
order. It is also easy to show Smith's conjecture in this case.
Perhaps an intermediate-difficulty assumption is that
C(R1,...,Rk; R) is the product of
1. C(R1,...,R{k-1}; Rk), i.e., the cost of the previous step, and
2. A constant n(R,f) that depends only on R and the number of
attributes of R that do not appear in R1,...,Rk (i.e.,
the number of free variables when we reach R).
Under this assumption, the input data is proportional to the
product of the number of relations and the maximum number of
attributes in a relation, which is polynomial in what we
would intuitively regard as the "size" of the input, i.e.,
the length of the relation schemes written out.
Now, at least, we have some hope of showing NP-completeness for
the optimality problem.
I also think we can attack Smith's conjecture: if we have
two sets of relation R1,...,Rm and T1,...,Tn, that do not
share any attributes, is their optimal order always an
interleaving of the optimal orders for the two sets?
I'll stick with my belief that it is not, at least for the
general cost model, probably for the intermediate-difficulty
model. In fact, the result is trivially true if we allow
C to be arbitrary, because once we have selected an R and a T
in our join, we are exercising parts of the C function that
were not exercised in finding the optimal orders for the R's or T's
separately, and ANYTHING can happen.
However, let's be fair, and assume that the cost
C(S1,...,Sk; S), where S is among the R's, is the product of
1. C(S1',...,Sp'; S), where S1',...,Sp' is the subsequence of S1,...,Sk
that are among the R's, and
2. A constant depending only on the subsequence of T's among S1,...,Sk.
Even with this assumption, we could suppose that the optimal
sequence for joining three R's has costs of 1, 50, 50, while
there is another sequence that has costs 1, 10, 100.
In isolation, we may prefer the former.
However, it also could be that when we interleave these with T's,
the constants (2-above) associated with the T's for a particular
interleaving are 1, 300, 200.
Then the first sequence has a cost of 25,001 and the second has 23,001.
Of course, things are not so simple, because we have to figure
in the cost of the T's, and we also have to recognize that this
may not be the optimal interleaving, all things considered.
Nonetheless, I think this point can be developed into a
concrete counterexample.
---Jeff
∂24-Oct-85 1602 BETSY@SU-CSLI.ARPA Visitor Policy
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 16:02:24 PDT
Date: Thu 24 Oct 85 15:57:35-PDT
From: Betsy Macken <BETSY@SU-CSLI.ARPA>
Subject: Visitor Policy
To: folks@SU-CSLI.ARPA
We've been getting some questions that made me think that it might be
useful to send this statement about our current visitor policy again:
VISITORS POLICY FOR 1985-86
Non-casual visitors to CSLI fall roughly into three groups:
(1) "Collaborators"; those whose visit is actively sought by a CSLI
researcher(s), for purposes of collaboration in some CSLI
project, or at any rate to work closely with such researcher(s).
Often travel money and other support is supplied from initiators
or area funds.
(2) "Sojourners"; those who are here mostly of their own volition,
finding it convenient to spend a sabbatical or other leave in
the midst of the resources offered here. Support is limited to
computer accounts and possibly shared office space.
(3) Special cases.
Visitors bring a great deal to CSLI, and independently of that we have
some obligation to share our good fortune. However, there are many
hidden and not so hidden costs. To keep things in balance, I intend
to adopt the following policies, mostly modest revisions of the
policies of the past.
Collaborators will be most welcome, of course. But:
a) We ask that the details of an impending visit, the duration, the
facilities needed, etc., be made available before the visit is
too impending. There are sudden opportunities, of course, but
in general a couple of weeks warning, via the forms available
from Bach-Hong, Elsie, or Jackie, seems reasonable. Of course,
the less the needs of the visitor, the less this matters.
b) We will allocate a limited amount of space at Ventura for
Collaborators; if this space is taken for the period in question,
by the time the details reach us, we may be unable to provide
any.
c) Please discuss the details of any proposed long-term visits
(much more than a month, say) with Betsy well in advance.
As to Sojourners, I think we would all agree that we are better off
with a few that we can treat pretty well, rather than a lot we don't
have time, space, or xerox paper for. So, we will let Sojourner
applications for Visiting Scholar status during a given academic year
(June to June) accumulate (except for special cases) until March 15 of
the previous year. Decisions will then be made on the basis of
projected available space and the credentials and projects of the
visitors. Thus Visiting Scholar status at CSLI will be somewhat more
meaningful, and somewhat less easy to obtain than the same status in
departments at Stanford. We will be nice to everyone, but only
committed to contributing to the space and computational needs of our
own Visiting Scholars. If you receive a request from someone wanting
to be a Sojourner, send it to Ingrid to be added to our applications
file.
Special cases. E.g., people whom we more actively encourage to come,
perhaps even providing some salary support or travel money. These
will be treated as special cases.
-------
∂24-Oct-85 1724 NILSSON@SU-SCORE.ARPA [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 17:24:29 PDT
Date: Thu 24 Oct 85 17:25:17-PDT
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
To: faculty@SU-SCORE.ARPA
Message-ID: <12153786875.16.NILSSON@SU-SCORE.ARPA>
What do we think about this? -Nils
---------------
Mail-From: TAJNAI created at 24-Oct-85 12:46:50
Date: Thu 24 Oct 85 12:46:50-PDT
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: Discussion on limiting size of Forum
To: nilsson@SU-SCORE.ARPA, jlh@SU-SONOMA.ARPA
Message-ID: <12153736184.13.TAJNAI@SU-SCORE.ARPA>
The following is a message that Terry and I drafted. You may want to
bring this issue to the attention of CSD/CSL faculty.
......................................................................
Two years ago the Forum Committee recommended that we limit membership
to 50 companies. The CSD/CSL Faculty disagreed and preferred to keep
membership open.
Membership is now 72. The Forum Committee is again discussing the
possibility of limiting membership. Faculty time is the resource that
seems to be the limiting factor.
Statistics for the past 4 years are as follows:
Number of Companies that belonged as of the annual meeting:
1981/82 29
1982/83 40
1983/84 55
1984/85 70
The Forum Committee is interested in your comments.
-------
-------
∂24-Oct-85 2129 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #26
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 21:29:23 PDT
Date: 24 Oct 85 2121-PDT
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #26
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Friday, 25 Oct 1985 Volume 1 : Issue 26
Today's Topics:
Second PARSYM Survey: Data Abstractions (continued!)
----------------------------------------------------------------------
Subject: Second PARSYM Survey: Data Abstractions
Date: Thu, 24 Oct 85 15:08:30 EDT
From: Paul Hudak <Hudak@YALE.ARPA>
Project: Para-Functional Programming: A Paradigm for Programming
Multiprocessor Systems
People: Paul Hudak, Lauren Smith (hudak@yale, smith-lauren@yale)
Place: Yale Department of Computer Science
To respond to this survey requires a little background material:
The main thesis of our work is that the parallelism in a purely
functional program is *implicit*, not needing any special notation
as is the case, for example, in imperative languages modified for
parallel computing. On the other hand, functional languages (or any
other languages, for that matter) do not generally provide ways to
*map* programs to particular multiprocessor topologies. Para-functional
programming provides this mapping ability via *annotations* to the
source program. One nice thing about this approach is that the
annotations can be made in such a way that the correctness of the
original program is preserved -- one can reason about the mapping
issues separately from issues of functional behavior.
There are two simple ideas:
1) the expression "exp $on pid" says evaluate exp on processor pid.
2) there is a dynamic variable $self that evaluates to the "currently
executing processor."
As described below, these annotations allow one to map data structures
to particular multiprocessor topologies. When used with recursion,
a surprisingly few number of annotations are generally needed.
1. Are you using or have you developed data structures or
abstractions specialized for parallel computing? Please
describe.
Partly because we wish to solve numerical as well as symbolic problems,
and partly because we want high degrees of parallelism, we have a
data structure called a "parallel array." The expression "mkv(n,f)"
creates a vector of length n whose i'th component has value f(i).
If I want to distribute that vector among a set of processors, I can
do so by mapping the body of f as I see fit. For example, by using:
f(i) = exp $on i
I am essentially placing the ith element of the vector on processor i.
Simple generalizations of this notion allow mapping arrays to meshes,
trees to hypercubes, etc.
2. In particular, do you use specialized data abstractions to
represent configurations of multiple processes? Please
describe.
As implicated above, our goal is generality, and thus we can tailor
most data structures to arbitrary topologies -- all it assumes is
some initial labeling (we use integers) of the processors. For example,
suppose I number a ring of n processors by 0,1,...,n-1. Then I can
create a function "map" that applies a function to each element of a
list, mapping the result sequentially to the processors around the ring:
map(f,l) = if null(l)
then ()
else cons( f(car(l)),
map(f,cdr(l)) $on right($self) )
right(p) = (p+1) mod n
This, of course, depends on the semantics of cons. If it is a
"parallel" cons then everything is OK. If it is a "lazy" cons then
we provide an additional annotaion, #, that basically says "do this
eagerly." So the last two lines of map might say:
... else cons( #f(car(l)),
#map(f,cdr(l)) $on right($self) )
# does *not* make the function strict; it just allows the computation
to proceed in parallel, and thus admits non-terminating *sub*-computations.
3. Do you use specialized data structures, a la FRONS, for
representing non-deterministic collections of data? Please
describe.
No. However the notion of non-determinism is not incompatible with
the ideas presented above, and the "standard" ways with which it is
dealt with in functional languages (for example FRONS or non-
deterministic merge) would seem to work just fine.
4. What are some useful references on the topic of data abstraction
in parallel computing (including your own)?
For para-functional programming:
Hudak, P. and Smith, L., "Para-functional Programming: A Paradigm
for Programming Multiprocessor Systems," to appear in Proceedings
of ACM Symposium on Principles of Programming Languages, January 1986.
An earlier version of the above paper is available as a tech report
from Yale: YALEU/DCS/TR-390, January 1985.
Papers by Warren Burton and Udi Shapiro are also relevant; they're
referenced in the above.
5. Other comments welcome.
The paper also talks about some obvious generalizations of the basic
ideas, such as control of operating system resources. It also gives
a formal denotational semantics of the mapping behavior, using a notion
of "execution trees," which seems to be useful as a step toward building
interpreters and tools for debugging.
------------------------------
End of PARSYM Digest
********************
∂24-Oct-85 2231 BRESNAN@SU-CSLI.ARPA "Case-Assignment by Nominals in Japanese"
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 22:31:03 PDT
Date: Thu 24 Oct 85 22:28:17-PDT
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: "Case-Assignment by Nominals in Japanese"
To: folks@SU-CSLI.ARPA
On Thursday, October 31, at 10:00 a.m. in the Ventura Hall
Conference Room, Masayo Iida will present her work abstracted
below. Written copies of the paper will be available on Monday
at the Ventural Hall Receptionist's desk.
Abstract:
Case-Assignment by Nominals in Japanese
In this paper I will discuss certain peculiar properties of a class of
Japanese deverbal nominals, which show verb-like properties in certain
environments: specifically, they assign verbal case and can be modified by
adverbs (`verbal case' includes nominative, accusative and dative, i.e.,
cases normally assigned by a verb). These case-assignment phenomena pose a
problem for current syntactic theories, which assume that verbs alone
assign such cases, while nouns do not. Now I have observed that a deverbal
nominal assigns verbal case only when it is concatenated with a suffix
bearing temporal information, which might be encoded with the feature
[+aspect]. The nominal assigns case when the following two conditions are
satisfied: (i) the nominal has a predicate-argument structure, and (ii) it
is concatenated with a suffix which bears an aspectual feature. I will
propose that (syntactic) category membership is not sufficient for
determining properties of case-assignment, adverb distribution, etc., and
suggest that the factors (i) and (ii) are perhaps more relevant.
--Masayo Iida
-------
∂25-Oct-85 0030 DAVIES@SUMEX-AIM.ARPA Wednesday meeting -- 9 am
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 00:30:51 PDT
Date: Fri, 25 Oct 1985 00:32 PDT
Message-ID: <DAVIES.12153864695.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: Wednesday meeting -- 9 am
I will talk about CAREL (for CARE-Lisp), a distributed-memory
multiprocessor Lisp. CAREL is designed to exploit the capabilities of
the CARE architecture and to accurately reflect the costs of
communicating data and code during execution of programs.
-- Byron
∂25-Oct-85 0935 BARWISE@SU-CSLI.ARPA Logic Seminar Cancelled today
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 09:34:53 PDT
Date: Fri 25 Oct 85 08:01:44-PDT
From: Jon Barwise <BARWISE@SU-CSLI.ARPA>
Subject: Logic Seminar Cancelled today
To: BBoard@SU-CSLI.ARPA, Folks@SU-CSLI.ARPA
Dag Westersthal's talk in the logic seminar, scheduled for today, is
postponed, due to Dag's sudden illness.
-------
∂25-Oct-85 0938 AAAI-OFFICE@SUMEX-AIM.ARPA Mark's confirmation
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 09:37:55 PDT
Date: Fri 25 Oct 85 09:00:51-PDT
From: AAAI <AAAI-OFFICE@SUMEX-AIM.ARPA>
Subject: Mark's confirmation
To: officers: ;
cc: aaai-OFFICE@SUMEX-AIM.ARPA
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12153957189.47.AAAI-OFFICE@SUMEX-AIM.ARPA>
Yesterday, we received a majority vote confirming Mark's appointment.
- Claudia
_
-------
∂25-Oct-85 1018 INGRID@SU-CSLI.ARPA House for Rent
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 10:13:51 PDT
Date: Fri 25 Oct 85 10:09:48-PDT
From: Ingrid Deiwiks - 497-3084 <INGRID@SU-CSLI.ARPA>
Subject: House for Rent
To: Folks@SU-CSLI.ARPA
Charming one bedroom house in College Terrace for rent. Tastefully
decorated with antiques, hardwood floors, oriental carpets, washer/dryer,
garbage disposal, dishwasher, low maintenance yard, patio. $1,000 per
month plus deposit. Term of rent: two months to one year, negotiable.
Please call 857-0676 after 1 pm.
PLEASE DO NOT REPLY TO THIS MESSAGE, BUT CALL THE ABOVE NUMBER.
-------
∂25-Oct-85 1032 INGRID@SU-CSLI.ARPA House for Rent
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 10:20:09 PDT
Date: Fri 25 Oct 85 10:16:36-PDT
From: Ingrid Deiwiks - 497-3084 <INGRID@SU-CSLI.ARPA>
Subject: House for Rent
To: Folks@SU-CSLI.ARPA
Three and a half bedroom house with two baths for rent (to family
only). Completely new kitchen with all the gadgets. Garden. Located
in Palo Alto, in walking distance from the main library and two parks.
Very close to schools. $1,300 per month. Term of rent: two months,
beginning November 11.
Please call 322-0187.
PLEASE DO NOT REPLY TO THIS MESSAGE, BUT CALL THE ABOVE NUMBER.
-------
∂25-Oct-85 1036 @SU-CSLI.ARPA:CLT@SU-AI.ARPA todays logic seminar is cancelled
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 10:32:10 PDT
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Fri 25 Oct 85 10:30:30-PDT
Date: 25 Oct 85 1013 PDT
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: todays logic seminar is cancelled
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
The seminar on logic and the foundations of mathematics to be
given by Dag Westerstahl today (Friday) at noon has been canceled
due to illness of the speaker. It will be rescheduled.
∂25-Oct-85 1036 RICHARDSON@SU-SCORE.ARPA November Sr. Faculty Meeting
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 10:35:24 PDT
Date: Fri 25 Oct 85 10:37:22-PDT
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: November Sr. Faculty Meeting
To: tenured@SU-SCORE.ARPA
Message-ID: <12153974759.22.RICHARDSON@SU-SCORE.ARPA>
The sr. faculty meeting ordinarily scheduled for the first week of November
will be postponed until the first week of December since there are no
pressing matters to discuss.
-------
∂25-Oct-85 1106 @SU-SCORE.ARPA:FEIGENBAUM@SUMEX-AIM.ARPA Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 11:05:31 PDT
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Oct 85 11:06:45-PDT
Date: Fri 25 Oct 85 11:06:37-PDT
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.ARPA>
Subject: Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
To: NILSSON@SU-SCORE.ARPA, faculty@SU-SCORE.ARPA
In-Reply-To: <12153786875.16.NILSSON@SU-SCORE.ARPA>
Message-ID: <12153980085.49.FEIGENBAUM@SUMEX-AIM.ARPA>
The following comment is intended to be practical, not cynical.
We have a waning of interest in industrial-liason "supply". We have seen a
gradual waxing of industrial-liason "demand". These are not now at
a comfortable equilibrium. They can be brought into equilibrium by the
normal method used for adjusting supply and demand: appropriate price
setting.
I suggest that the Forum price be raised 20% effective as soon as we can
reasonably do it, and 10% per year thereafter until the number of
members is "comfortable" for our faculty to support.
Ed
-------
∂25-Oct-85 1112 @SU-SCORE.ARPA:FEIGENBAUM@SUMEX-AIM.ARPA Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 11:12:52 PDT
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Oct 85 11:13:49-PDT
Date: Fri 25 Oct 85 11:13:41-PDT
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.ARPA>
Subject: Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
To: NILSSON@SU-SCORE.ARPA, faculty@SU-SCORE.ARPA
In-Reply-To: <12153980085.49.FEIGENBAUM@SUMEX-AIM.ARPA>
Message-ID: <12153981372.49.FEIGENBAUM@SUMEX-AIM.ARPA>
P.s. I believe that either the Chemistry for Biochemistry industrial-
affiliates program is at $25,000 per year!........Ed
-------
∂25-Oct-85 1118 @SU-SCORE.ARPA:FEIGENBAUM@SUMEX-AIM.ARPA Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 11:18:25 PDT
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Oct 85 11:14:26-PDT
Date: Fri 25 Oct 85 11:14:19-PDT
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.ARPA>
Subject: Re: [Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>: Discussion on limiting size of Forum]
To: NILSSON@SU-SCORE.ARPA, faculty@SU-SCORE.ARPA
In-Reply-To: <12153980085.49.FEIGENBAUM@SUMEX-AIM.ARPA>
Message-ID: <12153981486.49.FEIGENBAUM@SUMEX-AIM.ARPA>
oops, typo in the above. I meant "Chemistry OR Biochemistry..."
-------
∂25-Oct-85 1304 INGRID@SU-CSLI.ARPA Internal Faculty Fellowships
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 13:04:21 PDT
Date: Fri 25 Oct 85 13:01:16-PDT
From: Ingrid Deiwiks - 497-3084 <INGRID@SU-CSLI.ARPA>
Subject: Internal Faculty Fellowships
To: Folks@SU-CSLI.ARPA
STANFORD HUMANITIES CENTER
Announcement of Internal Faculty Fellowships: 1986-87
The Stanford Humanities Center will award as many as twelve Faculty
Fellowships for the academic year 1986-87. Of these, up to six will
be awarded to members of the Stanford faculty. (A similar number will
also be awarded to applicants from elsewhere, in two categories:
(a) fellowships for already well-established and usually tenured
scholars; (b) fellowships for junior, usually untenured, scholars who
teach at colleges or universities which do not have major graduate
schools or do not have doctoral programs in their own departments.)
Application forms and further information are available from
Ingrid@su-csli, or the Stanford Humanities Center, Mariposa House,
Stanford University, Stanford, CA 94305. Applications must be
completed by January 6, 1986. Awards will be announced not later than
mid-March 1986.
-------
∂25-Oct-85 1433 ullman@su-aimvax.arpa papers received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 14:33:33 PDT
Received: by su-aimvax.arpa with Sendmail; Fri, 25 Oct 85 14:30:07 pdt
Date: Fri, 25 Oct 85 14:30:07 pdt
From: Jeff Ullman <ullman@diablo>
Subject: papers received
To: nail@diablo
1. Parallel Evaluation of Recursive Rule Queries by Cosmodakis and
Kanellakis. This is the paper on sYryPS.
2. A State Transition Model for Distributed Query Processing by
LaFortune and Wong.
∂25-Oct-85 1559 MODICA@SU-SCORE.ARPA Class Lists
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Oct 85 15:57:43 PDT
Date: Fri 25 Oct 85 15:58:22-PDT
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: Class Lists
To: instructors@SU-SCORE.ARPA
Message-ID: <12154033196.35.MODICA@SU-SCORE.ARPA>
Class Lists are still here and eagerly waiting to be picked up.
See you soon,
Gina (MJH room 251)
-------
∂26-Oct-85 1019 BRESNAN@SU-CSLI.ARPA "Case-Assignment by Nominals in Japanese"
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 26 Oct 85 10:19:15 PDT
Date: Sat 26 Oct 85 10:17:41-PDT
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: "Case-Assignment by Nominals in Japanese"
To: folks@SU-CSLI.ARPA
Because of difficulties with the Xerox machine, Masayo Iida's
paper may not be available for distribution on Monday. Please
wait for further notice.
-------
∂27-Oct-85 1418 NILSSON@SU-SCORE.ARPA Student names
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 27 Oct 85 14:18:29 PST
Date: Sun 27 Oct 85 14:19:58-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Student names
To: faculty@SU-SCORE.ARPA
Message-ID: <12154550492.21.NILSSON@SU-SCORE.ARPA>
Apparently our CSD has had the policy of not releasing to
industrial inquirers names of our students who are expected to
graduate. (Of course, any company who joins the forum gets lots
of info about our students--and about many other things as well.)
If the policy is merely to protect the Forum, it sounds to me
like it's a bit extreme. We can hardly expect a company to pay $12K
per year just because they would like to get a list of names.
Maybe the policy was put in place to protect students from being pestered
by employers. Anyway, we can't seem to find mention of an official
policy--perhaps it's a very old one.
What do people think. I lean toward being more lenient about this, unless
I get an outpouring of sentiment against it. I'm particularly interested
in student comments. -Nils
-------
∂27-Oct-85 1447 NILSSON@SU-SCORE.ARPA Committees
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 27 Oct 85 14:47:09 PST
Date: Sun 27 Oct 85 14:48:17-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Committees
To: faculty@SU-SCORE.ARPA
Message-ID: <12154555647.21.NILSSON@SU-SCORE.ARPA>
There have been some minor reshufflings of our committees.
I believe everyone involved in the "shuffle" knows about it,
but for the record, here's the latest chart showing who is on
what committees. -Nils
1985-1986 CSD Committees
Key: x = new member F = fall quarter member
X = member who was on W = winter quarter member
this committee last year S = spring quarter member
c = chairman
C = chairman who was on this committee last year
| A | C | C | C | F | F |1st| F |Ind |Lib|MS| MS |Math|PhD |
| d | o | o | u | a | e | Yr| o |Prof|Pub|AI|Prog|Sci |Prog|
| m | m | l | r | c | l |Adv| r | | | | | | |
| i | p | l | r | i | l | | u | | | | | | |
| s | | o | i | l | o | | m | | | | | | |
| | | q | c | | w | | | | | | | | |
-------------------------------------------------------------------------------
Binford, T. | | | | | X | | | | | |X | x | | |
-------------------------------------------------------------------------------
Bosack, L. | | x | | | X | | | | | | | | | |
-------------------------------------------------------------------------------
Buchanan, B. | | | | | | | | | | C |C | | | |
-------------------------------------------------------------------------------
Cheriton, D. | X | | | | X | | | | | | | | | |
-------------------------------------------------------------------------------
Clancey, W. | | | | | | | | | | |X | | x | |
-------------------------------------------------------------------------------
Earnest, L. | | | | | C | | | | | | | | | |
-------------------------------------------------------------------------------
Feigenbaum, E. | x | | F | | | | | | | |X | | | |
-------------------------------------------------------------------------------
Floyd, R. | | x | | | | | | | | | | X | | |
-------------------------------------------------------------------------------
Genesereth, M. | | x | | X | x | | | | | |X | | | |
-------------------------------------------------------------------------------
Golub, G. | | X | | | | | | | | | | | X | |
-------------------------------------------------------------------------------
Grosz, B. | X | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Guibas, L. | | | | | | | | | | | | x | | x |
[1/2 LWOS '85-'86] | | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Hennessy, J. | | | | | | | | | | | | x | | |
-------------------------------------------------------------------------------
Herriot, J. | | | | | | | | | | | | | X | |
-------------------------------------------------------------------------------
Katevenis, M. | | | | | | | | | | | | | | |
[LWOS '85-'86 | | | | | | | | | | | | | | |
'86-'87] | | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Knuth, D. | | | | | | | | | | | | | | |
[Sabbat. '85-'86] | | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Lantz, K. | | x | S | x | | | | | | | | | | |
-------------------------------------------------------------------------------
Manna, Z. | | | | | | | | | | | | | | |
[LWOS '85-'86] | | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Mayr, E. | | | | | | | | | | | | | | |
[Sabbat. Fall '85 | | | W | x | | | | | | | | | C | |
Spring '86] | | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
McCarthy, J. | | | | | X | | | | C | | | | | x |
-------------------------------------------------------------------------------
!
| A | C | C | C | F | F |1st| F |Ind |Lib|MS| MS |Math|PhD |
| d | o | o | u | a | e | Yr| o |Prof|Pub|AI|Prog|Sci |Prog|
| m | m | l | r | c | l |Adv| r | | | | | | |
| i | p | l | r | i | l | | u | | | | | | |
| s | | o | i | l | o | | m | | | | | | |
| | | q | c | | w | | | | | | | | |
McCluskey, C. | x | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Miller, W. | | | | | | | | C | | | | | | |
-------------------------------------------------------------------------------
Nilsson, N. | | | F | | | x | x | | | | | | | |
-------------------------------------------------------------------------------
Oliger, J. | | | | | | | | | | | | C | | |
-------------------------------------------------------------------------------
Papadimitriou, C. | X | | | | | | | | | | | | | |
[Sabbat. Spr. '86] | | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Pratt, V. | | C | | | x | | | | | | | | | x |
-------------------------------------------------------------------------------
Reges, S. | | | | x | | | | | | | | | | |
-------------------------------------------------------------------------------
Reid, B. | | | | x | | | | | | | | | | x |
-------------------------------------------------------------------------------
Rindfleisch, T. | | | | | x | | | | | | | | | |
-------------------------------------------------------------------------------
Roberts, Eric (DEC)| x | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Rosenbloom, P. | | | | | | | | | | | X| | | x |
-------------------------------------------------------------------------------
Rosenschein, S. | | x | | | | | | | | | | | | |
-------------------------------------------------------------------------------
Tajnai, C. | | | | | | C | | X | | | | | | |
-------------------------------------------------------------------------------
Ullman, J. | | | | C | | | | | | | | | | |
-------------------------------------------------------------------------------
Wiederhold, G. | | | | | | | | | | | | X | x | |
-------------------------------------------------------------------------------
Winograd, T. | | | | | | | | X | | | | | | c |
-------------------------------------------------------------------------------
Yao, A. | c | | | | | | | | | | | | | |
-------------------------------------------------------------------------------
CSL Volunteers | | | W | | | | | | | | | | | |
-------------------------------------------------------------------------------
Industr. Vols. | x| | | | | | | | | | | | | |
-------------------------------------------------------------------------------
No. of Students: | 2 | 6 | 1 | 3 | 3 | 1 | | 2 | | 1 | 2| 2 | | 2 |
-------------------------------------------------------------------------------
!
Student Committee Members:
;; Key: [] means that the committee assignment was made prior to 9/85
;; {} indicates a slot that is not ordinarily on the committee
Admissions:
(1) Mike Dixon (MDIXON@SUSHI)
(2) Ramsey Haddad (HADDAD@SUSHI)
(3) Haym Hirsh (HIRSH@SUMEX)
Comprehensive Exam:
[AA] Allan Van Gelder (AVG@DIABLO)
[AI] Stuart Russell (RUSSELL@SUMEX)
(HW) & (SW) Jeff Naughton & Miriam Blatt
[MTC] Mike Dixon (MDIXON@SUSHI)
(NA) Ray Tuminaro
Colloquium (juice and cookies):
(1) Steve Vavasis (VAVASIS@SUSHI)
Curriculum:
[1] Anil Gangolli (GANGOLLI@SUSHI)
[2] Kathleen Kells (KELLS@SCORE)
{[3]} Devika Subramanian (SUBRAMANIAN@SUMEX)
Facilities:
(1) Joel Bion (BION@SCORE)
(2) Steve Tjiang (TJIANG@SCORE)
(3) Bruce Hitson [EE] (HITSON@SCORE)
Fellowships:
(1) William Lees (LEES@SUSHI)
Forum:
(1) Karen Pieper (PIEPER@SUSHI)
[2] Karen Scholz (SCHOLZ@SUSHI)
Library/Publications:
(1) Alejandro Quiroz (QUIROZ@SUSHI)
MSAI:
[1] Don Henager (HENAGER@SUMEX)
[2] Haym Hirsh (HIRSH@SUMEX)
(3) Naomi Rodolitz (RODOLITZ@SUMEX)
MS Program:
(1) Dave Fogelsong (FOGELSONG@SUSHI)
(2) James Fu (FU@SUSHI)
Evaluation of PhD program requirements:
(1) Eric Berglund (BERGLUND@PESCADERO)
(2) Peter Karp (KARP@SUMEX)
{3} Karen Scholz (SCHOLZ@SUSHI)
-------
∂27-Oct-85 1849 LANSKY@SRI-AI.ARPA PLANLUNCH REMINDER - Pat Hayes, Oct. 28
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 27 Oct 85 18:49:18 PST
Date: Sun 27 Oct 85 18:48:47-PST
From: LANSKY@SRI-AI.ARPA
Subject: PLANLUNCH REMINDER - Pat Hayes, Oct. 28
To: planlunch.dis: ;
POSSIBLE HISTORIES
Pat Hayes
Schlumberger Palo Alto Research, AI Lab
11:00 AM, MONDAY, October 28
SRI International, Building E, Room EJ228 (new conference room)
A history is a connected piece of space/time with 'natural' boundaries.
Using these as a basic ontology for talking about events, processes, etc.
has some advantages over some other frameworks, and doesn't have some of
the disadvantages which are sometimes attributed to it.
However, it does have one major problem, which is the difficulty of talking
about alternative possible futures, to allow planning to be done.
In this talk I discuss a new way of using histories which looks like
it can overcome this problem.
-------
∂28-Oct-85 0143 @SU-SCORE.ARPA:manfred%ucsc.csnet@CSNET-RELAY.ARPA techreport request!
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 01:43:12 PST
Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Oct 85 01:41:34-PST
Received: from ucsc by csnet-relay.csnet id a003596; 28 Oct 85 4:41 EST
Received: by vger.UCSC (4.12/4.7)
id AA01757; Sun, 27 Oct 85 17:55:29 pst
Date: Sun, 27 Oct 85 17:55:29 pst
From: manfred <@CSNET-RELAY.ARPA,@ucsc.CSNET (Manfred Warmuth):manfred@ucsc.CSNET>
To: CSD@su-score.arpa
Subject: techreport request!
Cc: dhaussle <@csnet-relay.arpa:dhaussle@udenver.CSNET>
I am trying to find a Ph.D. thesis done in CS or Math.
It probably appeared as a tech report.
Title: "Combinatorial entropy and uniform limit laws"
by J.M. Steele, 1975.
I would greatly appreciate it if you could mail a copy to each of the
following addresses:
Prof. Manfred Warmuth
Dep. of Comp. Sc.
265 Applied Sciences
Santa Cruz, Ca 95064
Prof. David Haussler
Dep. of Math. and Comp. Sc.
Univ. of Denver
Denver, Co 80208
Thank you very much!
Manfred Warmuth
∂28-Oct-85 0834 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 08:33:59 PST
Date: Mon 28 Oct 85 08:24:21-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch Series
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12154747899.15.RICHARDSON@SU-SCORE.ARPA>
The topic and speaker for the CSD Lunch on Oct. 29 at 12:15 in MJH 146 are
as follows: John Perry on "What's New at CSLI".
-------
∂28-Oct-85 0836 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar in Logic and the Foundations of Mathematics
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 08:36:46 PST
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 28 Oct 85 08:32:57-PST
Date: 28 Oct 85 0825 PST
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: Seminar in Logic and the Foundations of Mathematics
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
Speaker: John Etchemendy, Philosophy Dept. Stanford
Title: "Truth, the liar, and circular propositions"
Time: Friday, Nov.1, 12:00 noon.
Place: 383N (Math. Dept. Faculty Lounge)
S. Feferman
∂28-Oct-85 1533 IIDA@SU-CSLI.ARPA Talk this Thursday by Masayo Iida
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 15:33:17 PST
Date: Mon 28 Oct 85 15:27:43-PST
From: Masayo Iida <IIDA@SU-CSLI.ARPA>
Subject: Talk this Thursday by Masayo Iida
To: folks@SU-CSLI.ARPA
This is just a reminder that Masayo Iida will be presenting her paper `Case
Assignment by Nominals in Japanese' on Thursday Oct.31st at 10am in the
Ventura Conference room. This is part of the series of presentations by
the Morphology/Syntax/Discourse Interactions group. Copies of the paper
will be available on Tuesday 29th, assuming the Kodak machine to be
functioning.
--Masayo Iida
-------
∂28-Oct-85 1624 @SU-SCORE.ARPA:pratt@su-navajo.arpa Student names
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 16:24:19 PST
Received: from su-navajo.arpa by SU-SCORE.ARPA with TCP; Mon 28 Oct 85 16:25:40-PST
Received: by su-navajo.arpa with Sendmail; Mon, 28 Oct 85 16:25:30 pst
Date: Mon, 28 Oct 85 16:25:30 pst
From: Vaughan Pratt <pratt@su-navajo.arpa>
Subject: Student names
To: faculty@score
Non-forum members who wish either to advertise specific jobs or to do
on-campus recruiting do have the option of contacting the Career
Planning and Placement Center. In view of this, I am inclined to
regard provision of names as an additional service beyond this standard
one that we make available as a benefit of Forum membership.
-v
∂28-Oct-85 2233 @SU-SCORE.ARPA:HADDAD@SU-SUSHI.ARPA Re: Student names
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 22:33:33 PST
Received: from SU-SUSHI.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Oct 85 22:15:51-PST
Date: Mon 28 Oct 85 22:15:24-PST
From: Student Bureaucrats <HADDAD@SU-SUSHI.ARPA>
Subject: Re: Student names
To: NILSSON@SU-SCORE.ARPA
cc: bureaucrat@SU-SUSHI.ARPA, faculty@SU-SCORE.ARPA
Reply-To: bureaucrat@sushi
In-Reply-To: <12154550492.21.NILSSON@SU-SCORE.ARPA>
Message-ID: <12154899187.38.HADDAD@SU-SUSHI.ARPA>
This list of names of graduating students essentially
constitutes a "mailing list". Thus, we can immediately deduce a few
things about it:
1) Some students would delight in having their name passed
around to potentially interested people ("tearing up junk mail only
takes a few seconds, and I will get a whole bunch of interesting
offers that I never would have otherwise heard of").
2) Other students would feel violated and morally offended at
receiving the junk mail generated by the mailing list.
3) The list is worth money.
I have no strong feelings about the final decision, but would like to
make a few other comments:
1) While, personally, I think that the people who would feel
that they were being "violated" are quite silly, I would be derelict
in my duties as a student representative if I didn't recommend that:
if some such list is made available to all comers, then students
should have the option of having their names left off the "mailing
list".
2) While the list is worth money, it is not clear that we
should necessarily start a meter running for every possible action
that we can get a dime for.
3) Also, if it is decided that knowledge is power, and power
is money ("what's time, again?" -- sorry, you had to have seen the
movie) and that the list should only be formally given out to Forum
members, I would very strongly object if things went to the extreme
where the knowledge of who was expected to graduate became treated as
"proprietary" or "classified" knowledge, which no one was allowed to
communicate to anyone but Forum members. The Forum should be based on
"mutually benefitial" arrangements between the CSD and the companies.
It is very unbenefitial to the students if traditional "networking",
as a way of becoming aware of currently available jobs, were to dry
up.
Ramsey.
-------
∂29-Oct-85 0614 PATASHNIK@SU-SUSHI.ARPA AFLB abstracts
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 06:13:55 PST
Date: Tue 29 Oct 85 06:15:13-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: AFLB abstracts
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12154986536.11.PATASHNIK@SU-SUSHI.ARPA>
Besides AFLB, there's another talk this Thursday that might interest us:
Susan Landau, Wesleyan University and MSRI
Primes, Codes, and the National Security Agency---
How Number Theory Affects National Security
4:15PM Thursday, 31 October, in Terman, M33
Her lecture will be an expository talk on public key cryptosystems, RSA,
and the political controversy surrounding them. It will be non-technical
and aimed at an interdisciplinary audience in the sciences.
********* These are the next two regular AFLB's: *********
31-Oct-85 : Steven Fortune (ATT Bell Labs)
Sweepline Algorithms for Voronoi Diagrams
We present a simple, sweepline algorithm for computing Voronoi
diagrams. The algorithm is applicable to Voronoi diagrams arising
from a set of points, a set of line segments, and a set of weighted
points. In all cases it achieves an O(n log n) worst-case time bound,
and a linear space bound. The algorithm is easy to implement, since
it avoids the merge step required by divide-and-conquer algorithms.
An application to a version of the piano mover's problem will also be
discussed.
***** Time and place: October 31, 12:30 pm in MJ352 (Bldg. 460) ******
7-Nov-85 : Alejandro A. Sch\"affer (Stanford)
Shortest Prefix Strings Containing All
k-Element Permutations as Subsequences
What is the length of the shortest string consisting of elements of
{1,...,n} that contains as subsequences all permutations of any
$k$-element subset? Many authors have considered the special case
where k=n. In fact, this special case was posed by D.E. Knuth
(attributed to R. M. Karp) as problem 36 in the technical report
STAN-CS-72-292. This problem arose in analyzing shortest path
algorithms and flowgraph reduction algorithms.
I shall instead consider an incremental variation on the problem first
proposed by P.J. Koutas and T.C. Hu (Discrete Math. 11(1975) pp.
125-132). For a fixed value of n they ask for a string on the
alphabet {1,...,n} such that for all values of k <= n, the prefix
containing all permutations of any k-element subset as subsequences is
as short as possible. The problem can also be viewed as follows. For
k = 1 one needs n distinct digits to find each of the n possible
permutations. In going from k to k + 1, one starts with a string
containing all k-element permutations as subsequences, and one adds as
few digits as possible to the end of the string so that the new string
contains all k+1-element permutations. The catch is that for all
values of k most shortest prefixes for k cannot be extended minimally
to prefixes for k+1.
Until now only very weak results were known about this version with
the prefix restriction posed by Koutas and Hu. I shall describe an
*exact* solution using only *elementary* techniques.
I intend to make occasional use of the side blackboard in MJH352.
***** Time and place: November 7, 12:30 pm in MJ352 (Bldg. 460) ******
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352.
If you have a topic you would like to talk about in the AFLB seminar
please let me know. (Electronic mail: patashnik@su-sushi.arpa, phone:
(415) 497-1787). Contributions are wanted and welcome. Not all time
slots for this academic year have been filled.
More information about future and past AFLB meetings and topics are in
the file [SUSHI]<patashnik.aflb>aflb.bboard .
- Oren Patashnik
-------
∂29-Oct-85 0907 MODICA@SU-SCORE.ARPA Class Lists
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 09:07:21 PST
Date: Tue 29 Oct 85 09:04:38-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: Class Lists
To: Instructors@SU-SCORE.ARPA
Message-ID: <12155017377.34.MODICA@SU-SCORE.ARPA>
I'll be happy to send class lists through ID mail to any of you who wish
to express an interest in receiving them. Just let me know who and where
you are.
Gina
-------
∂29-Oct-85 1011 TREITEL@SUMEX-AIM.ARPA Conjunct ordering
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 10:11:26 PST
Received: from SUMEX-AIM.ARPA by su-aimvax.arpa with Sendmail; Tue, 29 Oct 85 10:08:49 pst
Date: Tue 29 Oct 85 10:08:10-PST
From: Richard Treitel <TREITEL@SUMEX-AIM.ARPA>
Subject: Conjunct ordering
To: nail@SU-AIMVAX.ARPA
Cc: treitel@SUMEX-AIM.ARPA
Message-Id: <12155028943.38.TREITEL@SUMEX-AIM.ARPA>
Following on the last meeting at which we discussed conjunct ordering, I
decided to at least try to back up Dave Smith's contention that the problem as
he thinks of it is NP-complete (I ended up agreeing with JDU that his book
does not contain such a result). So here's a proof. I expect to come to
tomorrow's meeting (10-30) to expound it. I have not made any attempt to win
$1 for the interleaving conjecture.
Optimal Conjunct Ordering is NP-complete Oct 85
Richard Treitel
A version of the problem of optimally ordering the conjuncts in a conjunctive
query is proved NP-complete.
The input to the problem is:
1. a set of terms, each being a predicate symbol followed by a list of symbols
which are either constants or variables. No function symbols. Usual
constraints as to types and arities apply between terms having any symbol in
common.
2. for each predicate symbol P, a number N(P), the number of facts stored in
the database which begin with that symbol.
3. for each distinct data type such that the query contains any variable of
that type, a number, the number of values in the domain of the type. For
infinite domains this is redundant because we will never try to solve a term
with such a variable free in it. For a variable V we write S(V) to denote the
number associated with the type of the variable.
The output is an ordered list of the same terms, which minimises the cost
function.
The cost of a list T1, ... Tn of terms is
the sum for i= 1 to n of C(T1, ... Ti), which in turn is defined by
C(T1) = N(P1) where Pj is the predicate symbol of Tj, and
C(T1, ... Ti+1) = C(T1, ... Ti) * N(Pi+1) / B(Ti+1)
where B(Tj) is the product of S(V) over all V occurring both in Tj and in some
Tk with k < j. These are the variables that will already be bound by the time
Tj is reached, and so their bindings will reduce the number of answers to Tj.
Now refer to page 201 of "Computers and Intractability" by Garey&Johnson, for
problem GT44, "Minimum Cut Linear Arrangement". This problem, which is
NP-complete, is stated as follows: given a graph G with n vertices, and an
integer K, find whether there is an ordering of the vertices (with the ordinal
number of a vertex v denoted by f(v)) such that, for every i with 1 < i < n,
the number of edges (u,v) of the graph such that f(u) <= i < f(v) is at most K.
The "1 < i < n" appears to be a typo for "1 <= i < n"; there is a puzzling
asymmetry in the problem as stated.
Suppose we are given an instance of this problem. Reduce it to a conjunct
ordering problem as follows:
Without loss of generality, there is no edge connecting a node to itself. For
each edge in G, create a variable, and for each vertex, a predicate symbol.
The term corresponding to each vertex consists just of its predicate symbol and
the variables of the edges that are incident to it. Consider the query which
is the conjunction of these terms. If a vertex has degree d, let the number
associated with its predicate symbol be n↑d, where n is the number of vertices
in the graph. For all variables V let S(V) be n↑2. I shall prove that there
exists an ordering of the query with cost less than n↑(K+1) iff there exists a
linear arrangement of the kind demanded.
Lemma: for a given ordering of the vertices in the graph (terms in the query),
the number of edges (u,v) in the graph such that f(u) <= i < f(v) (call this
number Cut(i)) is precisely the number of variables which appear just once in
the first i terms of the ordering.
Proof: immediate from the observation that every variable appears exactly
twice in the query.
Now C(T1, ... Ti) is just the product of N(Pj) for j from 1 to i divided by the
product of S(V) over all variables V appearing twice in (T1 ... Ti). Let W(i)
be the number of such variables. By the definition of N(Pi) given above, we
see that the product of N(Pj) for j from 1 to i is just n to the power (2*W(i)
+ Cut(i)). Therefore C(T1, ... Ti) is n↑Cut(i) for all i from 1 to n-1.
C(T1, ... Tn) is 1.
Thus if the vertices of the graph are arranged so that Cut(i) <= K for all
relevant i, the cost of the corresponding ordering of the terms of the query
will be at most
1 + (n-1) * n↑K
which is less than n↑(K+1), whereas if there is some i such that Cut(i) > K,
then the cost will be at least n↑(K+1).
-------
∂29-Oct-85 1129 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 11:29:23 PST
Date: Tue 29 Oct 85 11:31:12-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12155044059.25.RICHARDSON@SU-SCORE.ARPA>
Lunch today in MJH 146 at 12:15.
-------
∂29-Oct-85 1219 ullman@su-aimvax.arpa meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 12:19:04 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 29 Oct 85 12:12:03 pst
Date: Tue, 29 Oct 85 12:12:03 pst
From: Jeff Ullman <ullman@diablo>
Subject: meeting
To: nail@diablo
We'll continue our discussion of conjunctive queries.
Richard Treitel will present a proof of NP-completeness of
a formulation of this problem.
Let's meet at 11AM in 301MJH.
∂29-Oct-85 1537 CAROL@SU-CSLI.ARPA Demo of Dlion gloss package
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 15:37:00 PST
Date: Tue 29 Oct 85 15:31:57-PST
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: Demo of Dlion gloss package
To: Folks@SU-CSLI.ARPA
cc: Carol@SU-CSLI.ARPA
**************************************************************
**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**N
23-OCT-85
Hi-
I am planning a series of informal demoes of dandelion
packages. Short and specific, preferably held in the late
afternoon. We can also use these times to discuss other
concerns.
The first demo is of particular interest to linguists.
Michael Wescoat has written a gloss program to enable you
to format examples of sentences in one language which require
word by word glosses, plus more fluent renderings, in
another. This means true beautification of papers involving
translations. Michael will demo this program on 12 Nov.
at 4 p.m. in Trailer E.
Further subjects for this series could include: Notecards,
Loops, Sketch (advanced features and troubleshooting), Topics
and troubles in TEdit, Augmentations to TEdit (such as
TEditkeyplus, interface with emacs, indexing) ...
I would appreciate hearing from you all about which
of these demoes you would be likely to attend, as well
as requests and suggestions.
I've addressed this to "Folks" - If you wish to receive mail
about dandelions, please add yourself to the dlion-users
mailing list. (Send a note to "Requests".)
-Carol (321-2136, Ventura 28)
EWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION
**************************************************************
-------
∂29-Oct-85 1623 EMMA@SU-CSLI.ARPA Halloween
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 16:23:32 PST
Date: Tue 29 Oct 85 16:17:04-PST
From: Guy Fawkes
Subject: Halloween
Sender: EMMA@SU-CSLI.ARPA
To: folks@SU-CSLI.ARPA, bboard@SU-CSLI.ARPA, consultants@SU-CSLI.ARPA
Reply-To: bboard
Tel: 497-3479
←←
$ /..\
$ HALLOWEEN IS THIS THURSDAY | \
$ | \
######## / \
### ### DRESS UP AND JOIN THE SPIRIT OF
## ↑ ↑ ## THE DAY.
## ## ←←
### `'`' ### |..\ TOM WILL ALSO PROVIDE A SPECIAL TEA
######### / \
/ \
/ | Lasciate ogni speranza, voi ch'entrate
-------
∂29-Oct-85 2334 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu FST&TCS 5th Conference
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 23:34:02 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Tue 29 Oct 85 23:33:55-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Tue 29 Oct 85 23:29:08-PST
Received: by rsch.wisc.edu; Tue, 29 Oct 85 23:30:33 CST
Received: from crys.wisc.edu by rsch.wisc.edu; Tue, 29 Oct 85 15:45:12 CST
Message-Id: <8510292144.AA28617@crys.wisc.edu>
Received: from CS.COLUMBIA.EDU by crys.wisc.edu; Tue, 29 Oct 85 15:44:50 CST
Date: Tue 29 Oct 85 16:45:16-EST
From: Susan A Maser <MASER@CS.COLUMBIA.EDU>
Subject: FST&TCS 5th Conference
To: theory@CRYS.WISC.EDU
Status: R
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 29 Oct 85 23:30:17 CST (Tue)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
MESSAGE FROM S.N. MAHESHWARI, IIT DELHI:
Fifth Conference
FOUNDATIONS OF SOFTWARE TECHNOLOGY
AND
THEORETICAL COMPUTER SCIENCE
16-18 December 1985
INDIA INTERNATIONAL CENTRE, NEW DELHI, INDIA
PROGRAMME
Monday 16 December
0800-0900 Registration
0900-0915 Inauguration
0915-1015 Keynote Address
The Mathematics of Programming C.A.R. Hoare (Oxford University)
1015-1045 SESSION 1: Distributed and Concurrent Programming
Concurrent Programming Using Actors: Exploiting Large-Scale
Parallelism
G. Agha, C. Hewitt (Massachusetts Institute of Technology)
A New Class of High Level Programs for Distributed Computing
Systems
S. Ramesh, S.L. Mehndiratta (Indian Institute of Technology,
Bombay)
A Class of Termination Detection Algorithms for Distributed
Computations
D. Kumar (University of Texas)
New Protocols for the Election of a Leader in a Ring
A. Marchetti-Spaccamela (Universita' di Roma)
1245-1345 LUNCH
1345-1500 SESSION 2: Programming
Program Simplification via Symbolic Interpretation
C. Ghezzi, D. Mandrioli, A. Tecchio (Politecnico di Milano)
PROLOG-Based Inductive Theorem Proving
J. Hsiang, M. Srivas (State University of New York at
Stony Brook)
On the Calling Behaviour of Procedures*
D. Armbruster (Universitat Stuttgart)
1500-1530 COFFEE
1530-1700 SESSION 3: Algorithms
Approximation Algorithms for Planar Matching
S.M. Venkatesan (University of Minnesota)
Geometric Optimization and the Polynomial Hierarchy
C. Bajaj (Purdue University)
Deriving Object Octree from Images
J. Veenstra, N. Ahuja (University of Illinois)
Tuesday 17 December
0900-1000 Invited Talk
Deduction with Relation Matching
Z. Manna (Stanford University)
R. Waldinger (SRI International)
1000-1100 SESSION 4: Specifications
Recursively Defined Domains and Their Inductive Principles
F.A. Jenson (Aalborg University Center)
K.G. Larson (University of Edinburgh)
Large Database Specifications from Small Views
S. Khosla, T.S.E. Maibaum, M. Sadler (Imperial College)
1100-1130 COFFEE
1130-1315 SESSION 5: Theory
A Decision Method for Temporal Logic Based on Resolution
G. Venkatesh (Tata Institute of Fundamental Research)
A Generalization of the Parikh Vector for Finite and
Infinite Words
R. Siromoney, V. Rajkumar Dare (Madras Christian College)
The Implication Problem for Functional and Multivalued
Dependencies: An Algebraic Approach
V.S. Lakshmanan, C.E. Veni Madhavan (Indian Institute of
Science)
A Simple Characterization of Database Serializability*
K. Vidyasankar (Memorial University of Newfoundland)
1315-1415 LUNCH
1415-1515 Invited Talk
Who Needs to Verify Programs if You Can Test Them
A. Chandra (IBM Thomas J. Watson Research Centre)
1515-1545 COFFEE
1545-1715 SESSION 6: Semantics and Proof Techniques
Partial Correctness Semantics for CP[V,l,&]
V.A. Saraswat (Carnegie-Mellon University)
A Proof Technique for Rely/Guarantee Properties
E.W. Stark (State University of New York at Stony Brook)
A Complete Proof System for SCCS with Modal Assertions
G. Winskel (University of Cambridge)
Wednesday 18 December
0900-1000 Invited Talk
Demand-Driven Evaluation on Dataflow Machine
Arvind (Massachusetts Institute of Technology)
1000-1100 SESSION 7: VLSI
Design and Implementation of a Procedural VLSI
Layout System
J.M. Mata (Universidade Federal de Minas Gerais)
G. Vijayan (Georgia Institute of Technology)
VLSI Systems for Matrix Multiplication
K.H. Cheng, S. Sahni (University of Minnesota)
1100-1130 COFFEE
1130-1330 SESSION 8: Parallel Algorithms
Parallel Algorithms for Solving Certain Classes of
Linear Recurrences
S. Lakshmivarahan, S.K. Dhall (University of Oklahoma)
O(1) Parallel Time Incremental Graph Algorithms
D.D. Sherlekar, S. Pawagi, I.V. Ramakrishnan (University
of Maryland)
NC Algorithms for Comparability Graphs, Interval Graphs,
and Testing for Unique Perfect Matching
D. Kozen (Cornell University)
U.V. Vazirani (University of California, Berkeley)
V.V. Vazirani (Cornell University)
Fast and Efficient Parallel algorithms for the Exact
Inversion of Integer Matrices
V. Pan (State University of New York at Albany)
1330-1430 LUNCH
*Short Presentation
REGISTRATION INFORMATION
Charge Rs. 350 per person
includes a copy of the conference record,
refreshments, lunch and the Conference Dinner
Payment By cheque, bank draft or money order
in favour of Fifth Conference
Foundation of Software Technology and
Theoretical Computer Science
Or in cash
Advance Registration is recommended. Foreign participants should
inform of their intention to register at the address given below, but
due to bank charges and delays are advised to pay their charges at the
time of the Conference. Accomodation can be booked at hotels near the
conference venue. For more information write to the address given
below.
Address for all correspondence:
Dr. Niraj Sharma
FST&TCS 5
Department of Computer Science
Indian Institute of Technology
New Delhi, 110016
INDIA
Telegram: TECHNOLOGY NEW DELHI 110016 INDIA
-------------
TN Message #4
-------------
∂30-Oct-85 0615 PATASHNIK@SU-SUSHI.ARPA Special AFLB
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 06:15:29 PST
Date: Wed 30 Oct 85 06:17:04-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: Special AFLB
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12155249017.7.PATASHNIK@SU-SUSHI.ARPA>
This Friday there will be a special AFLB. Please note time (2:15) and
room (301) changes.
***************************************
1-Nov-85 (Friday) : Mark Krentel (Cornell)
The Complexity of Optimization Problems
Many important problems in computer science, such as CLIQUE, COLORING
and TRAVELLING SALESPERSON, arise naturally as optimization problems.
Typically one considers these problems as decision procedures, which
are often in NP, and one shows intractibility by showing them
NP-complete. We generalize the notion of NP-problems, in a manner
analogous to the definition of Valiant's class #P, by considering the
optimization version of the problem itself, and we show that this idea
yields a natural class of problems that we call OptP. This class
allows us to make finer distinctions on the complexity of optimization
problems than is possible in NP. For example, assuming P different
from NP, we can show that TRAVELLING SALESPERSON is strictly harder
than CLIQUE and that CLIQUE is strictly harder than BIN PACKING. We
then relate OptP to the class of functions computable in polynomial
time with an oracle for NP, by showing that every P↑{SAT} (P with an
oracle for SAT) function decomposes into an OptP function followed by
a polynomial time computation. This allows us to clear up a
misconception on the role of uniqueness for the problem of UNIQUELY
OPTIMAL TRAVELLING SALESPERSON as considered by Papadimitriou in the
1982 FOCS conference.
***** Time and place: November 1, 2:15 pm in MJ301 (Bldg. 460) ******
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352.
If you have a topic you would like to talk about in the AFLB seminar
please let me know. (Electronic mail: patashnik@su-sushi.arpa, phone:
(415) 497-1787). Contributions are wanted and welcome. Not all time
slots for this academic year have been filled.
More information about future and past AFLB meetings and topics are in
the file [SUSHI]<patashnik.aflb>aflb.bboard .
- Oren Patashnik
-------
∂30-Oct-85 0931 PHILOSOPHY@SU-CSLI.ARPA Josh Cohen
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 09:31:49 PST
Date: Wed 30 Oct 85 09:27:51-PST
From: Eve Wasmer <PHILOSOPHY@SU-CSLI.ARPA>
Subject: Josh Cohen
To: folks@SU-CSLI.ARPA
cc: friends@SU-CSLI.ARPA
The Philosophy Department is sponsoring a talk by Joshua Cohen from
M.I.T. The talk is titled "Structure, Choice, and Legitimacy in Locke's
Theory of Politics", and will be at 4:15 on Tuesday, November 5 in the
Philosophy Department Seminar Room, 90=92Q.
-------
∂30-Oct-85 0931 PHILOSOPHY@SU-CSLI.ARPA Josh Cohen
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 09:31:49 PST
Date: Wed 30 Oct 85 09:27:51-PST
From: Eve Wasmer <PHILOSOPHY@SU-CSLI.ARPA>
Subject: Josh Cohen
To: folks@SU-CSLI.ARPA
cc: friends@SU-CSLI.ARPA
The Philosophy Department is sponsoring a talk by Joshua Cohen from
M.I.T. The talk is titled "Structure, Choice, and Legitimacy in Locke's
Theory of Politics", and will be at 4:15 on Tuesday, November 5 in the
Philosophy Department Seminar Room, 90=92Q.
-------
∂30-Oct-85 1055 PHILOSOPHY@SU-CSLI.ARPA
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 10:55:28 PST
Date: Wed 30 Oct 85 10:48:39-PST
From: Eve Wasmer <PHILOSOPHY@SU-CSLI.ARPA>
To: folks@SU-CSLI.ARPA
cc: bboard@SU-CSLI.ARPA
Does anyone have a good condition Apple IIe for sale? Call Nancy Steege
on 497-2547 or electronic mail HF.NSS.
-------
∂30-Oct-85 1140 INGRID@SU-CSLI.ARPA Announcement
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 11:40:15 PST
Date: Wed 30 Oct 85 11:35:34-PST
From: Ingrid Deiwiks <INGRID@SU-CSLI.ARPA>
Subject: Announcement
To: SU-BBoards@SU-CSLI.ARPA, Folks@SU-CSLI.ARPA
ANNOUNCEMENT
Soto Symposia on Artificial Intelligence
----------------------------------------
A series of three symposia on AI will be held in the Soto Lounge,
Wilbur Hall, the first three Mondays in November, at 7 p.m. These
symposia are intended to inform Stanford students and others who are
interested about the nature of AI, its prospects, and the intellectual
and social issues to which it gives rise.
Monday, November 4, 7 p.m.
"What is AI?"
Barbara Grosz Computer Scientist, SRI
Consulting Professor of Computer Science,
Stanford
Stan Rosenschein Director of AI Lab, SRI
Consulting Professor of Computer Science,
Stanford
Matt Ginsberg Department of Computer Science, Stanford
Monday, November 11, 7 p.m.
"Can we make computers that think and talk?"
Terry Winograd Professor of Computer Science, Stanford
Brian Smith Computer Scientist, Xerox PARC
Consulting Professor of Philosophy,
Stanford
Nils Nilsson Professor of Computer Science and
Chair of Department of Computer Science,
Stanford
Monday, November 18, 7 p.m.
"Star Wars and Computation"
John McCarthy Professor of Computer Science, Stanford
David Redell DEC Research Laboratory
and possibly others
Each symposium will begin with short talks by the speakers, followed
by plenty of time for vigorous interchanges among the speakers and
with members of the audience.
Soto is the first dormitory in the Wilbur complex that one comes to
when walking out Escondido from the Undergraduate Library.
----------------------------------------------------------------------
<--UGLI Escondido Rd.
----------------------------------------------------------------------
xxxxxxxxxxxxxx X XXX XXX X
Soto --> X Wilbur X
Stern Hall X X
xxxxxxxxxxxxxx X Hall X
X X
X XXX XXX X
-------
∂30-Oct-85 1155 @SU-SUSHI.ARPA:vemuri@ngp.UTEXAS.EDU Re: Special AFLB
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 11:55:47 PST
Received: from ngp.UTEXAS.EDU by SU-SUSHI.ARPA with TCP; Wed 30 Oct 85 11:55:52-PST
Date: Wed, 30 Oct 85 13:28:25 cst
From: vemuri@ngp.UTEXAS.EDU (baba c. vemuri)
Posted-Date: Wed, 30 Oct 85 13:28:25 cst
Message-Id: <8510301928.AA24884@ngp.UTEXAS.EDU>
Received: by ngp.UTEXAS.EDU (4.22/4.22)
id AA24884; Wed, 30 Oct 85 13:28:25 cst
To: PATASHNIK@SU-SUSHI.ARPA, aflb.all@SU-SUSHI.ARPA
Subject: Re: Special AFLB
∂30-Oct-85 1639 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 16:39:32 PST
Date: Wed 30 Oct 85 16:38:45-PST
From: LANSKY@SRI-AI.ARPA
Subject: Next Monday's PLANLUNCH
To: planlunch.dis: ;
THOUGHTS ON AN INVITATION TO A (SURPRISE) BEHEADING
David Israel
SRI International, AI Center
11:00 AM, MONDAY, November 4
SRI International, Building E, Room EJ228 (new conference room)
Imagine you learn - from an authoritative source - that you will be
beheaded some afternoon of this coming week; say by Saturday at the
latest. No doubt you'd be unnerved. What, though, if you were also
told that the beheading would only take place if the following
condition were met: you would not know, say on the night before or the
morning of the event, that it was going to take place that afternoon.
So the beheading, if it is to take place at all, is to be a surprise.
Should your fears be allayed? Indeed, shouldn't they be completely
eliminated? There is a very plausible-seeming argument that you have
nothing to worry about. Unhappily, there seem to be lots of things
wrong this argument. What's up?
I want to look at this puzzle, with an eye to connecting together a
variety of considerations about belief, knowledge, time, and - of all
things - rational action. (This is going to be a PLANlunch seminar,
after all.) So, I invite you all to a seminar that I shall give some
day between now and next Wednesday. But, of course, you won't know,
say on the morning before the seminar,.........
-------
∂30-Oct-85 1732 EMMA@SU-CSLI.ARPA Newsletter October 31, No. 52
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 17:32:20 PST
Date: Wed 30 Oct 85 16:47:32-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter October 31, No. 52
To: friends@SU-CSLI.ARPA
Tel: 497-3479
!
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
October 31, 1985 Stanford Vol. 2, No. 52
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, October 31, 1985
12 noon TINLunch
Ventura Hall The Formation of Adjectival Passives
Conference Room by B. Levin and M. Rappaport
Discussion led by Mark Gawron
2:15 p.m. CSLI Seminar
Redwood Hall Foundations of Document Preparation
Room G-19 David Levy, CSLI and Xerox PARC
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Redwood Hall The Structure of Social Facts
Room G-19 Prof. John Searle, Dept. of Philosophy, UC Berkeley
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, November 7, 1985
12 noon TINLunch
Ventura Hall James Gibson's Ecological Revolution in Psychology
Conference Room by E. S. Reed and R. K. Jones
Discussion led by Ivan Blair, CSLI
(Abstract on page 2)
2:15 p.m. CSLI Seminar
Redwood Hall Phonology/Phonetics Seminar
Room G-19 Bill Poser and Paul Kiparsky
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Redwood Hall Meaning, Information and Possibility
Room G-19 Lofti A. Zadeh, Computer Science Division
University of California at Berkeley
(Abstract on page 2)
←←←←←←←←←←←←
!
Page 2 CSLI Newsletter October 31, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ABSTRACT OF NEXT WEEK'S TINLUNCH
James Gibson's Ecological Revolution in Psychology
E. S. Reed and R. K. Jones
From about 1950 until his death, James Gibson constantly argued for
a view of and a research program for cognitive psychology that
differed radically from the mainstream position. Today the dominant
view in cognitive psychology is of cognitive agents as information
processors, a view to which the advent of the modern digital computer
has given a considerable boost. In the paper for this week's
Tinlunch, Reed and Jones characterize and contrast the Gibsonian (or
ecological) and information processing approaches.
My intention is to use this article to lay out for discussion the
basic principles of the ecological approach. The issues to be
considered include: the need for cognitive psychology to study the
organism in a real environment; the ecological program of studying
the environmental sources of information; and the rejection of any
appeal to mental representations in psychological explanation.
--Ivan Blair
←←←←←←←←←←←←
NEXT WEEK'S CSLI SEMINAR
Abstract of Phonology/Phonetics seminar
Post-lexical phonological rules are associated with a hierarchy of
nested domains, which are systematically related to phrase structure.
There is growing evidence in favor of recent proposals that this
hierarchy is universal. In this talk, we show that Japanese has tonal
rules associated with each of the postulated post-lexical domains, and
propose a cross-linguistic account for one of the prosodic domains,
the phonological phrase. --Bill Poser, Paul Kiparsky
←←←←←←←←←←←←
NEXT WEEK'S CSLI COLLOQUIUM
Meaning, Information and Possibility
L.A. Zadeh, Computer Science Division, University of
California, Berkeley, CA 94720}
Our approach to the connection between meaning and information is in
the spirit of the Carnap-Bar-Hillel theory of state descriptions.
However, our point of departure is the assumption that any proposition,
p, may be expressed as a generalized assignment statement of the form
X `isr' C, where X is a variable which is usually implicit in p, C is
an elastic constraint on the values which X can take in a universe of
discourse U, and the suffix r in the copula `isr' is a variable whose
values define the role of C in relation to X. The principal roles are
those in which r is d, in which case C is a disjunctive constraint; and
r is c, p and g, in which cases C is conjunctive, probabilistic, and
granular, respectively. In the case of a disjunctive constraint, `isd'
is written for short as `is', and C plays the role of a graded possibility
distribution which associates with each point (or, equivalently,
state-description) the degree to which it can be assigned as a value to X.
This possibility distribution, then, is interpreted as the information
conveyed by p. Based on this interpretation, we can construct a set of
rules of inference which allow the possibility distribution of a
conclusion to be deduced from the possibility distributions of the
premises. In general, the process of inference reduces to the solution
of a nonlinear program and the traditional methods of deduction in
first-order logic are explained and illustrated by examples.
!
Page 3 CSLI Newsletter October 31, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ENVIRONMENTS GROUP MEETING
NoteCards: An Environment for Authoring and Idea Structuring
Randy Trigg, Xerox PARC
Monday, November 4, noon, Ventura Seminar Room
NoteCards is part of an ongoing research project in the Intelligent
Systems Lab at Xerox PARC investigating "idea processing" tasks, such
as interpreting textual information, structuring ideas, formulating
arguments, and authoring complex documents. NoteCards is intended
primarily as an idea structuring tool, but it can also be used as a
fairly general database system for loosely structured information.
The basic object in NoteCards is an electronic note card containing
an idea-sized unit of text, graphics, images, or whatever. Different
kinds of note cards are defined in an inheritance hierarchy of note
card types (e.g., text cards, sketch cards, query cards, etc.). On
the screen, multiple cards can be simultaneously displayed, each one
in a separate window having an underlying editor appropriate to the
card type.
Individual note cards can be connected to other note cards by
arbitrarily typed links, forming networks of related cards. At
present, link types are simply labels attached to each link. It is up
to each user to utilize the link types to organize the note card
network.
NoteCards also includes a filing mechanism for building
hierarchical structures using system-defined card and link types.
There are also browser cards containing node-link diagrams (i.e.,
maps) of arbitrary pieces of the note card network and Sketch cards
for organizing information in the form of drawings, text and links
spatially.
All of the functionality in NoteCards is accessible through a set
of well-documented Lisp functions, allowing the user to create new
types of note cards, develop programs that monitor or process the note
card network, and/or integrate other programs into the NoteCards
environment.
----------
PIXELS AND PREDICATES
The Caricature Generator
Susan Brennan
CSLI trailers, 1:00 p.m., Wednesday, November 6, 1985
In an investigation of primitives for image generation,
manipulation and perception, a face is an interesting example of an
image. I will briefly survey psychological literature on face
perception which treats such issues as piecemeal vs. configurational
recognition strategies. I'll describe an application where a
caricature of a face serves as a form of semantic bandwidth
compression. Then, with additional inspiration from art, computer
graphics and machine vision, I'll develop a theory of caricature.
Conditions permitting, there will be a demonstration of a program
which generates caricatures of faces from line drawings and provides
the user with a single exaggeration control with which the distortion
in the image (relative to a norm) can be turned up or down. I will
also show a videotape and refer to the work that Gill Rhodes and I
have been doing recently on perception of these caricatures.
!
Page 4 CSLI Newsletter October 31, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY AND SYNTAX
Case-Assignment by Nominals in Japanese
Masayo Iida
Thursday, October 31, 10:00 a.m., Ventura Conference Room
In this paper I will discuss certain peculiar properties of a class
of Japanese deverbal nominals, which show verb-like properties in
certain environments: specifically, they assign verbal case and can be
modified by adverbs (`verbal case' includes nominative, accusative and
dative, i.e., cases normally assigned by a verb). These
case-assignment phenomena pose a problem for current syntactic
theories, which assume that verbs alone assign such cases, while nouns
do not. Now I have observed that a deverbal nominal assigns verbal
case only when it is concatenated with a suffix bearing temporal
information, which might be encoded with the feature [+aspect]. The
nominal assigns case when the following two conditions are satisfied:
(i) the nominal has a predicate-argument structure, and (ii) it is
concatenated with a suffix which bears an aspectual feature. I will
propose that (syntactic) category membership is not sufficient for
determining properties of case-assignment, adverb distribution, etc.,
and suggest that the factors (i) and (ii) are perhaps more relevant.
--Masayo Iida
----------
LOGIC SEMINAR
``Truth, the Liar, and Circular Propositions''
John Etchemendy and Jon Barwise, Philosophy Dept. Stanford
Friday, Nov. 1, noon, 383N (Math. Dept. Faculty Lounge)
Unlike standard treatments of the Liar, we take seriously the
intuition that truth is, first and foremost, a property of
propositions (not of sentences), and the intuition that propositions
(unlike sentences) can be genuinely circular or nonwellfounded. To
model the various semantic mechanisms that give rise to the paradox,
we work within Peter Aczel's set theory, ZFC/AFA, a theory
equiconsistent with ZFC but with Foundation replaced by a strong
anti-foundation axiom. We give two separate models; one based on an
Austinian conception of propositions (according to which a proposition
claims that an actual or ``historical'' situation is of a specified
type), and one based on a Russellian conception (according to which
propositions are complexes of objects and relations). The models show
that the moral of the Liar depends in a crucial way on which
conception is adopted.
!
Page 5 CSLI Newsletter October 31, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
SUMMARY OF ENVIRONMENTS GROUP MEETING
October 28, 1985
Wolfgang Pollak of Kestrel spoke on the ADA programming environment
he helped develop at Rational Systems. By combining dedicated special
hardware (high-level-language oriented) with a monolingual operating
system / command language / environment (written entirely in ADA and
supported with specialized microcode and memory management), it was
possible to design the environment in a unified way using the language
itself as the structure. All storage is handled by making it possible
for arbitrary data objects in the language to be declared
``persistent,'' rather than having a separate concept of files. These
persistent objects are the locus of object management (access control,
versions, etc.). The environment is editor-based, with the commands
extended by using arbitrary function calls in the language. It
incorporates a concept of unitary action, which allows the user to
make a sequence of changes and then either commit (in which case they
all take effect at once) or abandon (in which case the state is as if
none of them ever happened). Wolf described a number of techniques
for making the environment incremental---for keeping the feel that
each small change takes effect as it is made, rather than waiting for
some large-scale redisplay or compile. Discussion emphasized the way
that a number of these issues and techniques could apply to other
environments.
-------
∂31-Oct-85 0917 TAJNAI@SU-SCORE.ARPA 1985 IBM Party
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 09:16:50 PST
Date: Thu 31 Oct 85 09:13:23-PST
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: 1985 IBM Party
To: CSD@SU-SCORE.ARPA, CSL-Everyone@SU-SIERRA.ARPA
Message-ID: <12155543259.21.TAJNAI@SU-SCORE.ARPA>
IBM is giving a party! Yes, a party! All those affiliated with CSD/CSL
are invited. The Forum is making the arrangements.
Thursday, November 14, 4 p.m. to 6 p.m., Faculty Club Gold Room.
Brent Hailpern, one of our illustrious alumni, conceived the idea two
years ago. The 1983 and 84 parties were so successful that he suggested
we do it again. So let's do it!!
Carolyn
-------
∂31-Oct-85 0926 EMMA@SU-CSLI.ARPA Halloween 3
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 09:26:20 PST
Date: Thu 31 Oct 85 09:23:24-PST
From: los diablos de CSLI
Subject: Halloween 3
Sender: EMMA@SU-CSLI.ARPA
To: folks@SU-CSLI.ARPA, bboard@SU-CSLI.ARPA
Reply-To: bboard
Tel: 497-3479
&
####### HALLOWEEN IS HERE. THE GHOSTS, THE DEVILS,
## ###
## ↑ ↑ ## THE BASEBALL PLAYERS, RONALD REAGANS, AND
### <> ##
## ## OTHERS BEGIN THERE ONCE YEARLY WALK THROUGH
########
THE REAL WORLD.
THEY WILL ALL BE SEEN AT CSLI'S THURSDAY AFTERNOON TEA MINGLING
WITH ORDINARY FOLK.
Her strong enchantments failing,
Her towers of fear in wreck,
Her limbecks dried of poisons
And the knife at her neck,
The Queen of air and darkness
Begins to shrill and cry,
`O young man, O my slayer,
To-morrow you shall die.'
O Queen of air and darkness,
I think 'tis truth you say.
And I shall die to-morrow;
But you will die to-day.
--A. E. Housman
-------
∂31-Oct-85 1323 EMMA@SU-CSLI.ARPA All Hallow's Eve
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 13:23:27 PST
Date: Thu 31 Oct 85 13:20:18-PST
From: Lilith
Subject: All Hallow's Eve
Sender: EMMA@SU-CSLI.ARPA
To: folks@SU-CSLI.ARPA, bboard@SU-CSLI.ARPA, consultants@SU-CSLI.ARPA
Reply-To: bboard
Tel: 497-3479
CSLI will be starting its tea/party at 3:15 in the Trailer
Classroom.
Please come and celebrate Halloween, the lengthening nights, etc.
-------
∂31-Oct-85 1450 EMMA@SU-CSLI.ARPA Halloween tea
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 14:50:31 PST
Date: Thu 31 Oct 85 14:38:57-PST
From: Cerebrus
Subject: Halloween tea
Sender: EMMA@SU-CSLI.ARPA
To: bboard@SU-CSLI.ARPA, folks@SU-CSLI.ARPA, consultants@SU-CSLI.ARPA
Reply-To: bboard
Tel: 497-3479
Because of the atypical October weather and because the trailer room
is already booked, the tea will be held on the deck.
`Two objects cannot occupy the same place at the same time'
-------
∂31-Oct-85 1509 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 15:09:42 PST
Date: Thu 31 Oct 85 14:46:22-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12155603875.26.LIBRARY@SU-SCORE.ARPA>
Lucid, The Dataflow Programming Language. APIC Studies In Data Processing
no. 22 by William Wadge and Edward Ashcroft. QA76.73.L83W33 1985.
The Acquisition Of Syntactic Knowledge. MIT Pres Series in AI. by Robert
Berwick. Q335.B48 1985.
Information Systems: Theoretical And Formal Aspects. IFIP. ed. by A.
Sernadas, J. Bubenko and A. Olive. QA75.5.I376 1985.
Metamodeling: A Study of Approximations in Queueing Models. Research
Reports and Notes. Computer Systems Series. by S. C. Agrawal
QA76.9.C65A38 1985.
Logic Testing and Design For Testability. MIT Press Computer Systems Series.
by Hideo Fujiwara. TK7868.L6F85 1985.
Model-Based Image Matching Using Location. MIT Press. ACM Distinguished
Dissertation 1984. by Henry Baird. TK7882.P3B35 1985.
A Manual of Intensinal Logic. CSLI Lecture Notes. by Johan van Benthem.
P51.C18 no. 1
Planning and Designing the Data Base Environment by Thomas Turk.
QA76.9.D3T85 1985.
The Massively Parallel Processor. Research Report and Notes. Scientific
Computation Series. MIT Press. ed. by J. L. Potter. QA76.5.M24375 1985.
Performance and Evaluation of Lisp Systems. Research Reports and Notes.
Computer Systems Series. MIT Press. by Richard Gabriel. QA76.73.L23G32 1985
SIMULA Information. Proceedings 9th Simula Users' Cong. University of
Geneva, Switzerland 1981. QA76.73.S55S55 1981.
Intuitionistic Type Theory. Studies in Proof Theory. Lecture Notes.
by Per Martin-lof. QA9.47.M37.
Computer Crime, Abuse, Liability and Security. A Comprehesive Bibliography
1970-1984. compiled by Reba Best and Cheryn Picquet. Z5703.4C63.B47 1985.
Microprocessors. EPO Applied Technology Series. by O A R Cornillie.
QA76.5C654 1985.
Introduction to Ada. by Paul Chirlian. QA76.73.A35C46 1984.
Getting Computers to Talk Like You and Me. Discourse Context, Focus, and
Semantics. (An ATN Model) by Rachel Reichman. P302.R45 1985.
Dictionary of Electrical, Electronics, and Computer Abreviation.
compiled by Phil Brown. REF TK9.B76 1985.
Anglo-American and German Abbreviations in Data Processing. by
Peter Wennrich. REF QA76.15W46 1984.
(Chinese Dictionary. English word alphabetized with Chinese
explanations.)by Fan, Jen-te REF QA76.15.J46 1981.
H. Llull
-------
∂31-Oct-85 1952 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu VLSI workshop announcement
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 19:52:07 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 31 Oct 85 19:52:35-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Thu 31 Oct 85 19:52:36-PST
Received: by rsch.wisc.edu; Thu, 31 Oct 85 21:30:46 CST
Message-Id: <8510311852.AA07342@rsch.wisc.edu>
Received: from Louie.UDEL.EDU by rsch.wisc.edu; Thu, 31 Oct 85 12:52:13 CST
Received: from csnet-pdn-gw by Louie.UDEL.EDU id aa27453; 31 Oct 85 0:20 EST
Received: from utd-cs by csnet-relay.csnet id ad25325; 31 Oct 85 0:14 EST
Date: 30 Oct 85 15:36:44-CST (Wed)
From: Makedon%utd-cs.csnet@csnet-relay.ARPA
To: udi%rsch.wisc.edu@csnet-relay.ARPA
Subject: VLSI workshop announcement
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 31 Oct 85 21:30:34 CST (Thu)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
C A L L F O R P A P E R S
AEGEAN WORKSHOP ON COMPUTING : VLSI ALOGORITHMS AND ARCHITECTURES
( A W O C - VLSI )
2ND INTERNATIONAL WORKSHOP ON PARALLEL COMPUTING AND VLSI
JULY 8 - 11, 1986
ATTICA, GREECE
ORGANIZED BY : THE COMPUTER TECHNOLOGY INSTITUTE OF GREECE (C.T.I)
SPONSORED BY : EATCS AND THE GENERAL SECRETARIAT OF SCIENCE AND
TECHNOLOGY, OF THE GREEK MINISTRY OF INDUSTRY,
ENERGY AND TECHNOLOGY
PROGRAM CHAIRPERSONS: Fillia Makedon & Paul Spirakis
TOPICS
Topics include, but are not limited to:
MODELS OF VLSI ARCHITECTURE SYSTOLIC ALGORITHMS
PARALLEL ALGORITHMS CAD ALGORITHMS
LAYOUT ALGORITHMS FAULT TOLERANCE
DISTRIBUTED COMPUTING VLSI TESTING
PAPERS
Authors are invited to submit six copies of a ten-page long
extended abstract BEFORE February 1, 1986 to one of the
following two addresses:
PROF. KURT MEHLHORN PROF. FILLIA MAKEDON
(PROGRAM CHAIRMAN) DEPT. OF COMPUTER SCIENCE
FB 10 INFORMATIK BOX 830688, M/S FN 3.3
UNIVERSITAT DES SAARLANDES THE UNIV. OF TEXAS AT DALLAS
66 SAARBRUCKEN RICHARDSON, TX 75083-0688
WEST GERMANY TEL (214) 690-2182
TEL 049-681-3023428 CSNET: Makedon@UTD-CS
Authors will be notified of ACCEPTANCE/REJECTION BY MARCH 15,
1986. Final papers are due by May 5, 1986.
PROCEEDINGS
The proceedings of the workshop will be published in the
Lecture Notes of Computer Science Series of Springer-Verlag.
PROGRAM COMMITTEE:
K. MEHLHORN (CHAIRMAN), W. GERMANY
I. FILOTTI, FRANCE J. REIF, USA
S. HAMBRUSCH, USA A. ROSENBERG, USA
T. LENGAUER, W. GERMANY P. SPIRAKIS, USA/GREECE
U. LAUTHER, W. GERMANY H. SUDBOROUGH, USA
T. LEIGHTON, USA P. VITANYI, NETHERLANDS
F. LUCCIO, ITALY C. PAPADIMITRIOU, USA/GREECE
F. MAKEDON, USA T. PAPATHEODOROU, GREECE
LOCAL ARRANGEMENTS COMMITTEE
C. MANOLOPOULOS, CHAIR (C.T.I., GREECE)
P. SPIRAKIS (USA, GREECE)
F. MAKEDON (USA)
T. PAPATHEODOROU (C.T.I. DIRECTOR, GREECE)
E. PROTONOTARIOS (N.T.U.A., GREECE)
FURTHER INFORMATION
AWOC-VLSI 86 will be held at a sea-side resort near Athens.
It will follow similar guidelines to the AMALFI-VLSI workshop
of 1984. The third day of the workshop will be left open for
activities which will include discussions/meetings between
VLSI theorists and invited VLSI designers from industry.
Further details about the workshop (and the final program)
will be sent to anyone who submits a paper. Others should
fill out the form provided below:
NAME AND MAILING ADDRESS:←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
TELEPHONE NUMBER:←←←←←←←←←←←←←←←←←←←← CSNET ADDRESS:←←←←←←←←←←←←←←
I PLAN TO: SEND A PAPER←←←←←←←← , PARTICIPATE←←←←←←←←←, (No. of
accompanying persons)←←←←←←←←←← , I WISH FURTHER INFORMATION←←←←←←←←,
SIGNATURE:←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
PLEASE SEND TO: PROF. PAUL SPIRAKIS
COMPUTER TECHNOLOGY INSTITUTE OF GREECE
P.O. BOX 1122
261 10 PATRAS, GREECE
TEL: 061-99-3174/3176
-------------
TN Message #5
-------------
∂01-Nov-85 0040 ACUFF@SUMEX-AIM.ARPA Explorers working at last
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 00:40:20 PST
Date: Fri 1 Nov 85 00:41:50-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Explorers working at last
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12155712278.85.ACUFF@SUMEX-AIM.ARPA>
To the best of my knowledge, all of our current Explorers except for
3 (Rosenbloom, Helix, and one pool) are functional. The other should join
the ranks in a matter of hours or a day or two. There is a release 2.0
(read "Getting Started with Explorers at KSL" near a console, or in
Sumex:<LispM>Exp-Intro.mss) on each machine, but I haven't gotten 1.0.2
configured. Let me know if you need it.
Enjoy,
-- Rich
-------
∂01-Nov-85 0631 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 5
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 06:31:48 PST
Received: from ucb-vax.berkeley.edu by SU-CSLI.ARPA with TCP; Fri 1 Nov 85 06:31:43-PST
Received: by UCB-VAX (5.29/5.14)
id AA01165; Wed, 30 Oct 85 12:21:37 PST
Received: by cogsci (5.31/5.13)
id AA01002; Wed, 30 Oct 85 12:05:18 PST
Date: Wed, 30 Oct 85 12:05:18 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8510302005.AA01002@cogsci>
To: cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Nov. 5
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar - IDS 237A
Tuesday, November 5, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``On the Intentional Contents of Mental States About Fictions''
Edward Zalta
Postdoctoral Fellow in Philosophy at C.S.L.I.
Acting Asst. Professor of Philosophy, Stanford University
In this seminar, I present a theory of intentional objects
some of which seem to serve nicely as the contents of mental
states about stories and dreams (no matter how bizarre they may
be). The theory yields a way of understanding utterances about
particular fictional characters and particular dream objects.
For the purposes of the talk, it will make no difference
whether one construes the theory ontologically as a theory
about what the world has to be like or has to have in it in
order for us to characterize properly such mental states, or
whether one construes the theory as just a canonical notation
for specifying the contents of (or mental representations
involved in) such states. Either way, one is left with a
domain over which operations may be defined to explain how we
get from one state to the next, and so the theory should be of
interest to cognitive scientists. The philosophical basis of
my work lies in a theoretical compromise between the views of
Edmund Husserl and Alexius Meinong, and it is consistent with
classical logic.
---------------------------------------------------------------
UPCOMING TALKS
November 12:Robert Wilensky, Computer Science, UCB
November 19:Richard Alterman, Computer Science, UCB
November 26:Eve Clark, Linguistics, Stanford
December 3:Bernard Baars, Langley Porter, UCSF
---------------------------------------------------------------
ELSEWHERE ON CAMPUS
Steven Pulos, UCB, will discuss ``Children's conceptions of
computers'' at the SESAME Colloquium on Monday, November 4,
4:00pm, 2515 Tolman Hall.
John Kruschki, UCB, will speak on ``Depth and the Configural
Orientation Effect'' at the Cognitive Psychology Colloquium,
Friday, November 8, 4:00pm, Beach Room, 3105 Tolman Hall.
∂01-Nov-85 1030 ullman@su-aimvax.arpa talk today
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 10:30:10 PST
Received: by su-aimvax.arpa with Sendmail; Fri, 1 Nov 85 10:25:17 pst
Date: Fri, 1 Nov 85 10:25:17 pst
From: Jeff Ullman <ullman@diablo>
Subject: talk today
To: nail@diablo
Don't forget the talk by Naqvi at the CS545 seminar, 3:15 today.
∂01-Nov-85 1130 WINOGRAD@SU-CSLI.ARPA Lost coat
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 11:18:41 PST
Date: Fri 1 Nov 85 11:14:06-PST
From: Terry Winograd <WINOGRAD@SU-CSLI.ARPA>
Subject: Lost coat
To: folks@SU-CSLI.ARPA
I think I left a dark blue jacket in Ventura on Monday or Tuesday.
It has my name in the label. If anyone has seen one around, please
let me know. Thanks -- t
-------
∂01-Nov-85 1203 COLEMAN@SU-CSLI.ARPA help the Aussies
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 12:02:31 PST
Date: Fri 1 Nov 85 11:58:25-PST
From: Carolyn Coleman <COLEMAN@SU-CSLI.ARPA>
Subject: help the Aussies
To: folks@SU-CSLI.ARPA
cc: coleman@SU-CSLI.ARPA
Avery Andrews of Linguistics at the Australian National University is working
to get things set up computationally in his department. He has sent me
several requests for information which I am not competent to provide.
Perhaps one of you helpful souls would like to fill him in:
1)Has anyone around CSLI produced a phonetic symbols font that could be used
or adapted to be used on a QMS LG1200 laser-printer?
2) Avery could send across his Scribe definitions for linguistics (including
LI, NLLT, Language and CUP bibliography formats) if anyone has use for such
things. He would also be interested in receiving such goodies.
--They haven't set up (LA)-TEX on their computer yet, but it will happen
fairly soon.
Avery's adress;
Avery Andrews <munnari!FACO.anu.oz!ANDALING@seismo.CSS.GOV>
Thanks in anticipation, Carolyn.
-------
∂01-Nov-85 1328 @SU-SCORE.ARPA:LES@SU-AI.ARPA Computer Facility Needs
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 13:27:28 PST
Received: from SU-AI.ARPA by SU-SCORE.ARPA with TCP; Fri 1 Nov 85 13:15:14-PST
Date: 01 Nov 85 1309 PST
From: Les Earnest <LES@SU-AI.ARPA>
Subject: Computer Facility Needs
To: Faculty@SU-SCORE.ARPA
We need your estimates of computer and other technical support needs over
at least the next five years. These needs are to be compiled, argued, and
integrated into three documents that are under development:
(1) a general 10 year plan for the department,
(2) a description of support needs over the next 5 years that
should be met by either the CSD Computer Facilities Group or
outside entities such as LOTS,
(3) a specific 2 year development plan for the Computer Facilities Group.
A response form is attached for your convenience.
Recognizing that most people's crystal balls get cloudy beyond a few
years, we think that it will suffice to get estimates from each group
covering the next five years and to use rather simple-minded extrapolation
to sketch departmental needs in the 1991-95 time period. If anyone wishes
to predict their needs for the full 10 year term, however, we will welcome
the additional information. Something on the order of one page of text is
about the right level of detail for this round.
We wish to use a predominently "top down" approach in formulating these
plans. General needs should be tied to one or more departmental programs
(e.g. "Instruction," "Research," or "Administration and Support"). While
specific suggestions, recommendations, or examples of solutions are
welcome, we mainly want functional requirements. For example, if you
recommend that we buy "25 XYZ machines," please also say something like
"in support of a course on Pernicious Programming involving about
125 students for two quarters each year with an average student needing
six hours/week on a terminal supporting PunkLisp."
You need not cover expansions needed to support the planned undergraduate
program. We shall extract these needs from Jeff Ullman's report,
"Resource Requirements for an Undergraduate Program in Computer Science."
It is understood that research programs will generally pay their own way
as far as computer facilities are concerned. We expect that some groups
plan to take responsibility for their own computer acquisitions and
system software development. In such cases, descriptions of computing
resources need not be very detailed but we still need to know about
computer space needs and any known special environmental requirements such
as unusual electrical power, special communication needs, or large
archival storage needs. Groups that plan to use departmental technical
facilities or who wish to consider this option should so state.
While we recognize that CSD technical, financial, and space resources are
limited, we plan to uninhibitedly accept and compile stated requirements
from all groups in the department at first. This compilation will be made
available to whoever is interested and we will then attempt to reconcile
the demands with resource limitations by traditional methods: cost/benefit
analysis, argumentation and political infighting.
The Facilities Committee will start thrashing on this November 11.
A timely response will be appreciated. Please send your projected needs,
questions or gripes to me, preferably by electronic mail.
Les Earnest (les@SAIL)
Facilities Committee Chair
-----------------------------------
To: CSD Facilities Committee
Subject: Estimated Computer Support Needs, 1986-1990
Name of Activity:
Instruction:
Terminal
Hrs./Week
Course Qtr./Yr. # Students /Student Languages & Special Needs
Research:
Departmental # of People
Service Needed (Full Time Equiv.) Languages & Special Needs
Project-Developed Space Required Special Needs
Computer Facilities (Square Feet) (e.g. communications, archiving)
Administration and Support:
# of People
Service Needed (Full Time Equiv.) Languages & Special Needs
∂01-Nov-85 1459 CHEADLE@SU-SCORE.ARPA Lost glasses
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 14:58:55 PST
Date: Fri 1 Nov 85 14:53:35-PST
From: Victoria Cheadle <CHEADLE@SU-SCORE.ARPA>
Subject: Lost glasses
To: csd@SU-SCORE.ARPA
Office: Margaret Jacks 258, 497-1519
Message-ID: <12155867333.33.CHEADLE@SU-SCORE.ARPA>
If anyone finds a pair of pink-framed glasses in a maroon case
around MJH, please return them to me. Some time between lunch
and 2:00, I misplaced them. The last place I remember seeing
them is right outside the rear entrance into MJH (1st floor).
Thanks,
Victoria
-------
∂01-Nov-85 1604 RINDFLEISCH@SUMEX-AIM.ARPA IBM S.J. Research Computer Science seminars 4 - 8 NOV 85
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 16:03:32 PST
Return-Path: <calendar.sjrlvm1%ibm-sj.csnet@CSNET-RELAY.ARPA>
Received: from CSNET-RELAY.ARPA by SUMEX-AIM.ARPA with TCP; Fri 1 Nov 85 14:12:05-PST
Received: from ibm-sj by csnet-relay.csnet id ar12736; 1 Nov 85 16:19 EST
Date: Wed, 30 Oct 85 18:19:35 PST
From: IBM San Jose Research Laboratory Calendar <calendar%ibm-sj.csnet@CSNET-RELAY.ARPA>
Reply-To: IBM-SJ Calendar <CALENDAR%ibm-sj.csnet@CSNET-RELAY.ARPA>
To: CSNET <"IBM Computer Science Subset distribution list"@ibm-sj.CSNET>
Subject: IBM S.J. Research Computer Science seminars 4 - 8 NOV 85
ReSent-Date: Fri 1 Nov 85 16:03:44-PST
ReSent-From: T. C. Rindfleisch <Rindfleisch@SUMEX-AIM.ARPA>
ReSent-To: SSRG-Systems-Staff@SUMEX-AIM.ARPA, AAP@SUMEX-AIM.ARPA
ReSent-Message-ID: <12155880103.24.RINDFLEISCH@SUMEX-AIM.ARPA>
IBM San Jose Research Lab
5600 Cottle Road
San Jose, CA 95193
CALENDAR
November 4 - 8, 1985
Mon., Nov. 4 Horizon Lecture Series
1:00 P.M. THE TELECOMMUNICATIONS ENVIRONMENT AND CHALLENGES
Auditorium Dr. Oshman will discuss ROLM's history and the
telecommunications environment facing IBM and ROLM.
Dr. K. Oshman, IBM Vice President
and President of ROLM Corporation
Host: F. Mayadas
Tues., Nov. 5 Computer Science Seminar
2:00 P.M. SPUR - SYMBOLIC PROCESSING USING RISCS
Aud. A We describe the architecture of a multiprocessor
risc workstation under development at
University of California, Berkeley. Each
processor consists of a custom VLSI CPU, an
integrated cache controller/memory management
unit, and a floating point co-processor. The
processor includes architectural support for
Common LISP, the cache controller implements a
hardware multiprocessor cache coherency scheme,
the memory management unit performs high
performance virtual memory translation without a
TLB, and the floating point unit implements the
I.E.E.E. standard. Six faculty and twenty
students are involved in the project, which
spans from i.c. design to programming
environments research. The project is being
supported by DARPA under the Strategic Computing
Initiative.
R. Katz, Computer Science Division,
University of California, Berkeley
Host: L. Cabrera
Thurs., Nov. 7 Computer Science Seminar
2:00 P.M. THE SPRITE NETWORK OPERATING SYSTEM
Aud. B Sprite is a new network operating system built
by a team of graduate students and myself as
part of the SPUR workstation project. The talk
will focus on three parts of Sprite: the
filesystem, process offloading, and the virtual
memory system. The filesystem will provide a
single shared Unix-like file hierarchy
distributed across several servers. Clients
will use dynamically-constructed prefix tables
to associate file names with servers. Sprite
will include a process offloading mechanism that
allows jobs to be run on idle workstations in
the same way that jobs may be placed in
background in Unix. The virtual memory system
will be Unix-like with simple extensions to
permit shared data segments and synchronization.
I'll talk about how changes in technology have
influenced the design of Sprite and try to
convince you that a) a simple network filesystem
eliminates the need for other network protocols,
RPC, name servers, and the like; b) magnetic
disks will soon be obsolete; and c) paging is
also about to be obsolete (sort of).
J. Ousterhout, Computer Science Division,
University of California, Berkeley
Host: L. Cabrera
-----------------------------------------------------------------------
For further information on individual talks, please contact the host
listed above.
Visitors, please arrive 15 minutes early. IBM is located on U.S.
101, about 7 miles south of Interstate 280. Exit at Monterey Road
(82) and turn right if you took 101 south (left for 101 north.)
Continue straight, ignoring the sign for 82, then follow signs for
Cottle Road. The Research Laboratory is IBM Building 028.
For more detailed directions, please phone the Research Lab
receptionist at (408) 256-3028.
IBM San Jose Research mails out both the complete research calendar
and a computer science subset calendar. Send requests for inclusion
in either electronic mailing list to CALENDAR at IBM-SJ.CSNET
(CALENDAR at SJRLVM1 on VNET), specifying computer science or general.
∂01-Nov-85 1644 TAJNAI@SU-SCORE.ARPA honors
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 16:43:43 PST
Date: Fri 1 Nov 85 16:44:30-PST
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: honors
To: Faculty@SU-SCORE.ARPA
Message-ID: <12155887525.12.TAJNAI@SU-SCORE.ARPA>
If you received a special honor in 1985, please let me know.
I know of John McCarthy received the first Award for Research
Excellence at the IJCAI. George Dantzig was elected to the National
Academy of Engineering and won the 1985 Harvey Prize in the field of
science and technology by Technion.
Don't be modest. Let me know.
Carolyn
-------
∂01-Nov-85 1656 INGRID@SU-CSLI.ARPA House for Rent
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 16:55:57 PST
Date: Fri 1 Nov 85 16:53:19-PST
From: Ingrid Deiwiks <INGRID@SU-CSLI.ARPA>
Subject: House for Rent
To: SU-BBoards@SU-CSLI.ARPA, Folks@SU-CSLI.ARPA
***********************************************************************
HOUSE FOR RENT *** HOUSE FOR RENT *** HOUSE FOR RENT *** HOUSE FOR RENT
***********************************************************************
3 1/2 bedrooms, 2 bathrooms, completely new kitchen with all gadgets.
Garden. Located in Palo Alto, in walking distance of main library and
two parks. Very close to schools. For family only. Terms of rent:
Two months starting November 11. $1,000 per month.
Please call 322-0187.
PLEASE DO NOT REPLY TO THIS MESSAGE BUT CALL THE ABOVE NUMBER.
-------
∂01-Nov-85 1752 COLEMAN@SU-CSLI.ARPA
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 17:52:06 PST
Date: Fri 1 Nov 85 17:49:02-PST
From: Carolyn Coleman <COLEMAN@SU-CSLI.ARPA>
To: folks@SU-CSLI.ARPA
cc: coleman@SU-CSLI.ARPA
-------
∂01-Nov-85 1822 ACUFF@SUMEX-AIM.ARPA Leaving Explorers
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 18:21:54 PST
Date: Fri 1 Nov 85 18:23:02-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Leaving Explorers
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12155905461.13.ACUFF@SUMEX-AIM.ARPA>
I suggest leaving Explorers booted, but with the brightness turned
down, much as 36xx's are treated.
-- Rich
-------
∂01-Nov-85 1829 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu Call for papers - PODC
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 18:29:30 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Fri 1 Nov 85 18:26:48-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Fri 1 Nov 85 18:26:52-PST
Received: by rsch.wisc.edu; Fri, 1 Nov 85 20:08:32 CST
Message-Id: <8511020154.AA06059@rsch.wisc.edu>
Received: from IBM-SJ.ARPA (ibm-sj.csnet) by rsch.wisc.edu; Fri, 1 Nov 85 19:54:30 CST
Date: 1 Nov 85 13:35:07 PST
From: HALPERN@IBM-SJ.ARPA
Subject: Call for papers - PODC
To: theory@rsch.wisc.edu
Status: R
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 01 Nov 85 20:08:20 CST (Fri)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
CALL FOR PAPERS:
5th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing
(PODC)
Calgary, Alberta, Canada
August 11-13, 1986
Original research contributions are sought that address fundamental
issues in the theory and practice of distributed and concurrent systems.
Topics of interest include, but are not limited to,
the following aspects of concurrent and distributed systems:
* Principles of distributed computation derived from
practical experience with working systems
* Algorithms and complexity
* Specification, semantics, and verification
* Programming languages and programming language constructs
* Fault tolerance
Important Dates:
Jan. 31, 1986: Abstracts due
Apr. 11, 1986: Authors informed of acceptance or rejection
May 16, 1986: A final copy of each accepted paper due, typed on special
forms for inclusion in the conference proceedings
Please send ELEVEN copies of a detailed abstract
(not the complete paper), with the address,
telephone number, and NET ADDRESS (if available) of a
contact author on the cover page, to the program chair:
Dr. J. Halpern
Department K53/801
IBM Almaden Research Center
650 Harry Road
San Jose, CA 95120-6099
The abstract should be no more than 10 DOUBLE-SPACED TYPEWRITTEN PAGES.
It must include a clear description of the problem being discussed,
comparisons with extant work, and a section on major original
contributions. There should be enough detail provided for the
program committee to make a decision.
SUBMISSIONS ARRIVING LATE OR DEPARTING SIGNIFICANTLY FROM THESE
GUIDELINES RISK REJECTION WITHOUT CONSIDERATION OF THEIR MERITS.
The Program Committee consists of:
David Cheriton, Stanford
Cynthia Dwork, IBM Almaden
Nissim Francez, Technion
Hector Garcia-Molina, Princeton
Joseph Halpern, IBM Almaden
Butler Lampson, DEC
Richard Ladner, U. of Washington
Paul Leach, Apollo Computer, Inc.
Michael Merritt, AT&T Bell Laboratories
Doron Rotem, Waterloo University/Lawrence Berkeley Labs
Sam Toueg, Cornell
Conference Chair: Ernest Chang, Alberta Research Council
Publicity Chair: Tiko Kameda, Simon Fraser University
-------------
TN Message #6
-------------
∂02-Nov-85 1158 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ernie.berkeley.edu
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 2 Nov 85 11:58:00 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Sat 2 Nov 85 11:55:25-PST
Received: from ucb-vax.berkeley.edu by SU-SCORE.ARPA with TCP; Sat 2 Nov 85 11:55:35-PST
Received: by ucb-vax.berkeley.edu (5.31/1.2)
id AA20741; Sat, 2 Nov 85 11:40:53 PST
Received: by ernie (5.31/5.13)
id AA14212; Sat, 2 Nov 85 11:40:39 PST
Date: Sat, 2 Nov 85 11:40:39 PST
From: karp@ernie.berkeley.edu (Richard Karp)
Message-Id: <8511021940.AA14212@ernie>
To: aflb.local@su-score.arpa, allmsgs@ernie.berkeley.edu,
csfac@ernie.berkeley.edu, csmsgs@ernie.berkeley.edu,
theory-b@ernie.berkeley.edu, theory-f@ernie.berkeley.edu
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley (415)642-0143
Seminars in Computational Complexity
Tuesday, November 5 10:30 MSRI Lecture Hall
Deborah Joseph "Separating Complexity Classes" (continued)
Tuesday, November 5 2:00 MSRI Lecture Hall
Ron Book "Algorithmic Problems of Certain Finitely Presented Groups and
Monoids"
Tuesday, November 5 4:00 MSRI Lecture Hall
Ker-I Ko "Applying Discrete Complexity Theory to Numerical Computation"
Wednesday, November 6 4:15 60 Evans
MSRI-EVANS WEDNESDAY LECTURES
Hendrik Lenstra "Applied Number Theory"
Thursday, November 7 4:00 MSRI Lecture Hall
STRUCTURE IN COMPLEXITY THEORY
Juris Hartmanis Title to be Announced
∂03-Nov-85 1923 LANSKY@SRI-AI.ARPA planlunch reminder -- Monday/11am/David Israel
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 3 Nov 85 19:23:49 PST
Date: Sun 3 Nov 85 19:24:18-PST
From: LANSKY@SRI-AI.ARPA
Subject: planlunch reminder -- Monday/11am/David Israel
To: planlunch.dis: ;
THOUGHTS ON AN INVITATION TO A (SURPRISE) BEHEADING
David Israel
SRI International, AI Center
11:00 AM, MONDAY, November 4
SRI International, Building E, Room EJ228 (new conference room)
Imagine you learn - from an authoritative source - that you will be
beheaded some afternoon of this coming week; say by Saturday at the
latest. No doubt you'd be unnerved. What, though, if you were also
told that the beheading would only take place if the following
condition were met: you would not know, say on the night before or the
morning of the event, that it was going to take place that afternoon.
So the beheading, if it is to take place at all, is to be a surprise.
Should your fears be allayed? Indeed, shouldn't they be completely
eliminated? There is a very plausible-seeming argument that you have
nothing to worry about. Unhappily, there seem to be lots of things
wrong this argument. What's up?
I want to look at this puzzle, with an eye to connecting together a
variety of considerations about belief, knowledge, time, and - of all
things - rational action. (This is going to be a PLANlunch seminar,
after all.) So, I invite you all to a seminar that I shall give some
day between now and next Wednesday. But, of course, you won't know,
say on the morning before the seminar,.........
-------
∂03-Nov-85 2051 BARWISE@SU-CSLI.ARPA Visitor
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Nov 85 20:51:17 PST
Date: Sun 3 Nov 85 20:48:08-PST
From: Jon Barwise <BARWISE@SU-CSLI.ARPA>
Subject: Visitor
To: Folks@SU-CSLI.ARPA, bboard@SU-CSLI.ARPA
Professor Giuseppe Longo, from Pisa, will be visiting CSLI this week,
Monday through Thursday. As you may know, he works in the area of
denotational semantics, models of the lambda calculus, and types. If
you wish to contact him, send a message to Brown@csli, who will see
that it gets to him. We will schedule a talk if a suitable time can
be found.
-Jon Barwise
-------
∂04-Nov-85 0917 INGRID@SU-CSLI.ARPA Symposia on AI
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 09:15:53 PST
Date: Mon 4 Nov 85 09:09:56-PST
From: Ingrid Deiwiks <INGRID@SU-CSLI.ARPA>
Subject: Symposia on AI
To: SU-Bboards@SU-CSLI.ARPA, Folks@SU-CSLI.ARPA
ANNOUNCEMENT
Soto Symposia on Artificial Intelligence
----------------------------------------
A series of three symposia on AI will be held in the Soto Lounge,
Wilbur Hall, the first three Mondays in November, at 7 p.m. These
symposia are intended to inform Stanford students and others who are
interested about the nature of AI, its prospects, and the intellectual
and social issues to which it gives rise.
Monday, November 4, 7 p.m.
"What is AI?"
Barbara Grosz Senior Computer Scientist, SRI
Consulting Professor of Computer Science,
Stanford
Stan Rosenschein Director of AI Lab, SRI
Consulting Professor of Computer Science,
Stanford
Matt Ginsberg Department of Computer Science, Stanford
Monday, November 11, 7 p.m.
"Can we make computers that think and talk?"
Terry Winograd Professor of Computer Science, Stanford
Brian Smith Computer Scientist, Xerox PARC
Consulting Professor of Philosophy,
Stanford
Nils Nilsson Professor of Computer Science and
Chair of Department of Computer Science,
Stanford
Monday, November 18, 7 p.m.
"Star Wars and Computation"
John McCarthy Professor of Computer Science, Stanford
David Redell DEC Research Laboratory
and possibly others
Each symposium will begin with short talks by the speakers, followed
by plenty of time for vigorous interchanges among the speakers and
with members of the audience.
Soto is the first dormitory in the Wilbur complex that one comes to
when walking out Escondido from the Undergraduate Library.
----------------------------------------------------------------------
<--UGLI Escondido Rd.
----------------------------------------------------------------------
xxxxxxxxxxxxxx X XXX XXX X
Soto --> X Wilbur X
Stern Hall X X
xxxxxxxxxxxxxx X Hall X
X X
X XXX XXX X
-------
∂04-Nov-85 1002 LIBRARY@SU-SCORE.ARPA Applied Numerical Mathematics--New Journal In Math/CS Library
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 10:01:52 PST
Date: Mon 4 Nov 85 10:00:34-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Applied Numerical Mathematics--New Journal In Math/CS Library
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12156600422.31.LIBRARY@SU-SCORE.ARPA>
We have received the first five issues of a new journals titled Applied
Numerical Mathematics. The first issue of volume one is dated January
1985. It is published by North-Holland and is subtitled transactions of
IMACS, International Association for Mathematics and Computers in Simulation.
The editors-in-chief are R. Vichnevetsky, Dept. of CS, Rutgers Univ. and
R. Stepleman, Exxon Research & Engineering.
H. Llull
-------
∂04-Nov-85 1036 BARWISE@SU-CSLI.ARPA Talk on semantics of types in computer languages
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 10:35:53 PST
Date: Mon 4 Nov 85 10:32:52-PST
From: Jon Barwise <BARWISE@SU-CSLI.ARPA>
Subject: Talk on semantics of types in computer languages
To: BBoard@SU-CSLI.ARPA, Folks@SU-CSLI.ARPA, CLT@SU-AI.ARPA
"The semantics of types and terms and their equivalences for various
lambda-calculi", by Prof. Giuseppe Longo, Wednesday, 12 noon, in the
Ventura Conference Room.
Abstract: Lambda calculus provides the core of functional programming
as it is based on the key notions of functional abstraction and
application. The first part of the lecture will present an will
present an introductory account of the main type disciplines and their
semantics. First-order polymorphism and its motivations are also
surveyed. In the second part, the semantic equivalence of typed terms
will be discussed. The relation between types and terms gives us an
insight into second-order polymorphism (parametric types) and its
semantics.
(Please forward this to others who might be interested.)
-------
∂04-Nov-85 1140 HOLDEN@SU-CSLI.ARPA Friday afternoon drinking sessions
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 11:40:23 PST
Date: Mon 4 Nov 85 11:34:51-PST
From: Gary Holden <HOLDEN@SU-CSLI.ARPA>
Subject: Friday afternoon drinking sessions
To: Folks@SU-CSLI.ARPA, Linguists@SU-CSLI.ARPA
THIS IS YOUR FIRST (THOUGH NOT LAST) CHANCE TO CHECK OUT THE NEW
STUDENTS! (In a socially acceptable manner.)
COME ONE, COME ALL! TO THE WEEKLY SOIREE.
Place: The Greenberg Room, Linguistics Dept.
Date: Friday November 8 (and subsequent Fridays ad infinitum)
Time: 5 to 6 pm.
-------
∂04-Nov-85 1229 ACUFF@SUMEX-AIM.ARPA What Explorer files to keep
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 12:29:01 PST
Date: Mon 4 Nov 85 12:30:07-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: What Explorer files to keep
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12156627647.24.ACUFF@SUMEX-AIM.ARPA>
People with "personal" Explorers--
Each Explorer has all the system source files and such on it. For
people with Explorers in their offices, you can safely delete most if
not all of these directories, especially since these files will be
sought after on other hosts anyway. You might be interested in the
TI-EXAMPLES and UNSUPPORTED directories, though you needn't keep a
copy on your own machine.
-- Rich
-------
∂04-Nov-85 1250 ACUFF@SUMEX-AIM.ARPA Booting Lisp Machines
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 12:49:57 PST
Date: Mon 4 Nov 85 12:50:36-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Booting Lisp Machines
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12156631376.24.ACUFF@SUMEX-AIM.ARPA>
We have arrived at the time when simply shouting "Can I boot?" is
no longer sufficient to insure that rebooting a TI or Symbolics lisp
machine at Welch Rd. will not burn someone else. Given that there is
still a possibility of a machine you need to boot being in use by
someone else via the network (even in office machines, though this is
more remote), I suggest that the following protocol be followed when
booting:
1. Use Peek's Server display (System or Select P and then S) to see
who, if anyone, is using your machine as a server.
2. Contact the person(s) using your machine, and tell them you'd like
to reboot so that they have a chance to close down gracefully.
Voice, intercom, and Converse are all good potential ways to
contact the other users.
3. After the other users have given you the go ahead, use (si:shutdown).
Please keep me informed of any problems with this scheme, and, if
necessary, I'll write software to automate the process somewhat.
-- Rich
-------
∂04-Nov-85 1436 ULLMAN@SU-SCORE.ARPA new contract
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 14:36:34 PST
Date: Mon 4 Nov 85 14:17:23-PST
From: Jeffrey D. Ullman <ULLMAN@SU-SCORE.ARPA>
Subject: new contract
To: faculty@SU-SCORE.ARPA
cc: hanrahan@SU-SCORE.ARPA
Message-ID: <12156647176.15.ULLMAN@SU-SCORE.ARPA>
In discussions with Clive Liston it appeared to me that we do
not have to sign the new form if we have
a) signed an old PATENT agreement, and
b) are not taking UNIVERSITY funds for production of copyrightable
material, e.g., writing code for hire for the library.
---Jeff
-------
∂04-Nov-85 1546 GINSBERG@SUMEX-AIM.ARPA change to SIGlunch mailing list
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 15:46:17 PST
Date: Mon 4 Nov 85 15:39:57-PST
From: Matt Ginsberg <GINSBERG@SUMEX-AIM.ARPA>
Subject: change to SIGlunch mailing list
To: aam@SU-AI.ARPA, abarbanel@SUMEX-AIM.ARPA, adrienne@SU-SUSHI.ARPA,
aiello@SUMEX-AIM.ARPA, ali@SU-SCORE.ARPA, alpert@SU-SCORE.ARPA,
altenberg@SUMEX-AIM.ARPA, altman@SUMEX-AIM.ARPA, amarel@SUMEX-AIM.ARPA,
andy@SU-SUSHI.ARPA, arun@SU-SCORE.ARPA, ashok@SU-SCORE.ARPA,
bach@SU-SCORE.ARPA, banks@SUMEX-AIM.ARPA, barnes@SU-SCORE.ARPA,
barnhouse@SUMEX-AIM.ARPA, barr@SUMEX-AIM.ARPA, bennett@SUMEX-AIM.ARPA,
berlin@SU-SCORE.ARPA, bertrand@SUMEX-AIM.ARPA, bhayes-roth@SU-SCORE.ARPA,
bischoff@SUMEX-AIM.ARPA, blum@SUMEX-AIM.ARPA, breese@SUMEX-AIM.ARPA,
bright@SU-SCORE.ARPA, brinkley@SUMEX-AIM.ARPA, brouillet@SUMEX-AIM.ARPA,
brown@SUMEX-AIM.ARPA, brutlag@SUMEX-AIM.ARPA, buchanan@SUMEX-AIM.ARPA,
cck@SU-AI.ARPA, chou@SUMEX-AIM.ARPA, clancey@SUMEX-AIM.ARPA,
clarkson@SU-SCORE.ARPA, combs@SUMEX-AIM.ARPA, condran@SUMEX-AIM.ARPA,
cooper@SUMEX-AIM.ARPA, cwc@SU-AIMVAX.ARPA, croft@SU-SAFE.ARPA,
damon@SU-SCORE.ARPA, davies@SU-SIERRA.ARPA, davies@SUMEX-AIM.ARPA,
de2smith@SUMEX-AIM.ARPA, delagi@SUMEX-AIM.ARPA, dfeldman@SUMEX-AIM.ARPA,
dirk@SU-PSYCH.ARPA, dlo@SU-AI.ARPA, dmc@SU-AI.ARPA, downs@SUMEX-AIM.ARPA,
drogers@SUMEX-AIM.ARPA, edozien@SU-SCORE.ARPA, ejs@SU-AI.ARPA,
engelmore@SUMEX-AIM.ARPA, erlbaum@SUMEX-AIM.ARPA, fagan@SUMEX-AIM.ARPA,
feigenbaum@SUMEX-AIM.ARPA, frayman@SUMEX-AIM.ARPA, frd@SU-AI.ARPA,
friedland@SUMEX-AIM.ARPA, fu@SUMEX-AIM.ARPA, gardner@SUMEX-AIM.ARPA,
Gelman@SUMEX-AIM.ARPA, genesereth@SU-SCORE.ARPA, Gibbons@SU-SCORE.ARPA,
Ginsberg@SUMEX-AIM.ARPA, ginn@SUMEX-AIM.ARPA, gluck@SU-PSYCH.ARPA,
golding@SUMEX-AIM.ARPA, goldstein@SU-SCORE.ARPA, greep@SU-CSLI.ARPA,
grosof@SU-SCORE.ARPA, haggerty@SUMEX-AIM.ARPA, hahn@SU-SCORE.ARPA,
haken@SUMEX-AIM.ARPA, harvey@SUMEX-AIM.ARPA, hasling@SUMEX-AIM.ARPA,
henager@SUMEX-AIM.ARPA, henjum@SU-SUSHI.ARPA, hewett@SUMEX-AIM.ARPA,
hirsh@SUMEX-AIM.ARPA, holtzman@SUMEX-AIM.ARPA, horvitz@SUMEX-AIM.ARPA,
hsu@SUMEX-AIM.ARPA, JED@SU-AI.ARPA, jimison@SUMEX-AIM.ARPA,
jjf@SU-SCORE.ARPA, jk@SU-AI.ARPA, jmc-LISTS@SU-AI.ARPA, jmm@SU-AI.ARPA,
johnmark@SU-WHITNEY.ARPA, Johnson@SUMEX-AIM.ARPA, jordan@SU-PSYCH.ARPA,
joyce@SUMEX-AIM.ARPA, jvc@SU-SCORE.ARPA, kahn@SUMEX-AIM.ARPA,
kahoun@SUMEX-AIM.ARPA, kapsner@SUMEX-AIM.ARPA, karnicky@SU-SCORE.ARPA,
King@SUMEX-AIM.ARPA, koo@SUMEX-AIM.ARPA, kramer@SUMEX-AIM.ARPA,
kuhn@SUMEX-AIM.ARPA, Kunz@SUMEX-AIM.ARPA, langlotz@SUMEX-AIM.ARPA,
Lenat@SUMEX-AIM.ARPA, leu@SUMEX-AIM.ARPA, lgd@SU-AI.ARPA,
lichtarge@SUMEX-AIM.ARPA, London@SUMEX-AIM.ARPA, mackinlay@SUMEX-AIM.ARPA,
MAFFLY@SUMEX-AIM.ARPA, maslin@SUMEX-AIM.ARPA, mclaughlin@SUMEX-AIM.ARPA,
meindl@SU-SIERRA.ARPA, merchant@SUMEX-AIM.ARPA,
mis-students@SUMEX-AIM.ARPA, mis%su-psych@SU-SCORE.ARPA, ML@SU-AI.ARPA,
msgs@SU-PSYCH.ARPA, musen@SUMEX-AIM.ARPA, nagle@SU-SCORE.ARPA,
navarro@SUMEX-AIM.ARPA, nii@SUMEX-AIM.ARPA, Nilsson@SU-SCORE.ARPA,
nishimura@SUMEX-AIM.ARPA, ng@SU-SUSHI.ARPA, nsingh@SUMEX-AIM.ARPA,
novak@SUMEX-AIM.ARPA, pchen@SU-SCORE.ARPA, PCohen@SUMEX-AIM.ARPA,
pednault@SU-SCORE.ARPA, petrone@SUMEX-AIM.ARPA, pkr@SU-AI.ARPA,
qian@SU-SCORE.ARPA, rac@SU-AI.ARPA, rappaport@SUMEX-AIM.ARPA,
RDG@SU-AI.ARPA, rennels@SUMEX-AIM.ARPA, rep@SU-AI.ARPA,
richer@SUMEX-AIM.ARPA, Rindfleisch@SUMEX-AIM.ARPA, rohn@SUMEX-AIM.ARPA,
rosenschein@SUMEX-AIM.ARPA, russell@SUMEX-AIM.ARPA, rww@SU-AI.ARPA,
saraiya@SUMEX-AIM.ARPA, sbarnes@SUMEX-AIM.ARPA, scales@SUMEX-AIM.ARPA,
selig@SU-SUSHI.ARPA, sg@SU-AI.ARPA, shawn@SU-SCORE.ARPA,
shng@SUMEX-AIM.ARPA, Shortliffe@SUMEX-AIM.ARPA, sleeman@SUMEX-AIM.ARPA,
smith@SUMEX-AIM.ARPA, Su-bboard@SU-SCORE.ARPA, Subramanian@SUMEX-AIM.ARPA,
Suwa@SUMEX-AIM.ARPA, takahashi@SU-AI.ARPA, Teach@SUMEX-AIM.ARPA,
Terry@SUMEX-AIM.ARPA, theodorou@SU-SCORE.ARPA, tthompson@SUMEX-AIM.ARPA,
TOB@SU-AI.ARPA, treitel@SUMEX-AIM.ARPA, tsuji@SUMEX-AIM.ARPA,
tthompson@SUMEX-AIM.ARPA, Tu@SUMEX-AIM.ARPA, Turner@SUMEX-AIM.ARPA,
unruh@SUMEX-AIM.ARPA, val@SU-AI.ARPA, VGA@SU-AI.ARPA, Vian@SUMEX-AIM.ARPA,
vp@SU-SCORE.ARPA, Walker@SUMEX-AIM.ARPA, wallace@SU-SCORE.ARPA,
waltzman@SU-SCORE.ARPA, Warren@SRI-AI.ARPA, washington@SUMEX-AIM.ARPA,
Welch-road@SUMEX-AIM.ARPA, whitney@SUMEX-AIM.ARPA,
Wiederhold@SUMEX-AIM.ARPA, wilkins@SUMEX-AIM.ARPA, wulfman@SUMEX-AIM.ARPA,
yan@SU-SCORE.ARPA, ym@SU-AI.ARPA, yue@SU-SCORE.ARPA
Message-ID: <12156662207.75.GINSBERG@SUMEX-AIM.ARPA>
A.#Internetλ,
genesereth@λSU-SCORE.ARPA.#Internetλ,
Gibbons@λSU-SCORE.ARPA.#Internetλ,
Ginsberg@λSUMEX-AIM.ARPA.#Internetλ,
ginn@λSUMEX-AIM.ARPA.#Internetλ,
gluck@λSU-PSYCH.ARPA.#Internetλ,
golding@λSUMEX-AIM.ARPA.#Internetλ,
goldstein@λSU-SCORE.ARPA.#Internetλ,
greep@λSU-CSLI.ARPA.#Internetλ,
grosof@λSU-SCORE.ARPA.#Internetλ,
haggerty@λSUMEX-AIM.ARPA.#Internetλ,
hahn@λSU-SCORE.ARPA.#Internetλ,
haken@λSUMEX-AIM.ARPA.#Internetλ,
harvey@λSUMEX-AIM.ARPA.#Internetλ,
hasling@λSUMEX-AIM.ARPA.#Internetλ,
henager@λSUMEX-AIM.ARPA.#Internetλ,
henjum@λSU-SUSHI.ARPA.#Internetλ,
hewett@λSUMEX-AIM.ARPA.#Internetλ,
hirsh@λSUMEX-AIM.ARPA.#Internetλ,
holtzman@λSUMEX-AIM.ARPA.#Internetλ,
horvitz@λSUMEX-AIM.ARPA.#Internetλ,
hsu@λSUMEX-AIM.ARPA.#Internetλ,
JED@λSU-AI.ARPA.#Internetλ,
jimison@λSUMEX-AIM.ARPA.#Internetλ,
jjf@λSU-SCORE.ARPA.#Internetλ,
jk@λSU-AI.ARPA.#Internetλ,
jmc-LISTS@λSU-AI.ARPA.#Internetλ,
jmm@λSU-AI.ARPA.#Internetλ,
johnmark@λSU-WHITNEY.ARPA.#Internetλ,
Johnson@λSUMEX-AIM.ARPA.#Internetλ,
jordan@λSU-PSYCH.ARPA.#Internetλ,
joyce@λSUMEX-AIM.ARPA.#Internetλ,
jvc@λSU-SCORE.ARPA.#Internetλ,
kahn@λSUMEX-AIM.ARPA.#Internetλ,
kahoun@λSUMEX-AIM.ARPA.#Internetλ,
kapsner@λSUMEX-AIM.ARPA.#Internetλ,
karnicky@λSU-SCORE.ARPA.#Internetλ,
King@λSUMEX-AIM.ARPA.#Internetλ,
koo@λSUMEX-AIM.ARPA.#Internetλ,
kramer@λSUMEX-AIM.ARPA.#Internetλ,
kuhn@λSUMEX-AIM.ARPA.#Internetλ,
Kunz@λSUMEX-AIM.ARPA.#Internetλ,
langlotz@λSUMEX-AIM.ARPA.#Internetλ,
Lenat@λSUMEX-AIM.ARPA.#Internetλ,
leu@λSUMEX-AIM.ARPA.#Internetλ,
lgd@λSU-AI.ARPA.#Internetλ,
lichtarge@λSUMEX-AIM.ARPA.#Internetλ,
London@λSUMEX-AIM.ARPA.#Internetλ,
mackinlay@λSUMEX-AIM.ARPA.#Internetλ,
MAFFLY@λSUMEX-AIM.ARPA.#Internetλ,
maslin@λSUMEX-AIM.ARPA.#Internetλ,
mclaughlin@λSUMEX-AIM.ARPA.#Internetλ,
meindl@λSU-SIERRA.ARPA.#Internetλ,
merchant@λSUMEX-AIM.ARPA.#Internetλ,
mis-students@λSUMEX-AIM.ARPA.#Internetλ,
mis%su-psych@λSU-SCORE.ARPA.#Internetλ,
ML@λSU-AI.ARPA.#Internetλ,
msgs@λSU-PSYCH.ARPA.#Internetλ,
musen@λSUMEX-AIM.ARPA.#Internetλ,
nagle@λSU-SCORE.ARPA.#Internetλ,
navarro@λSUMEX-AIM.ARPA.#Internetλ,
nii@λSUMEX-AIM.ARPA.#Internetλ,
Nilsson@λSU-SCORE.ARPA.#Internetλ,
nishimura@λSUMEX-AIM.ARPA.#Internetλ,
ng@λSU-SUSHI.ARPA.#Internetλ,
nsingh@λSUMEX-AIM.ARPA.#Internetλ,
novak@λSUMEX-AIM.ARPA.#Internetλ,
pchen@λSU-SCORE.ARPA.#Internetλ,
PCohen@λSUMEX-AIM.ARPA.#Internetλ,
pednault@λSU-SCORE.ARPA.#Internetλ,
petrone@λSUMEX-AIM.ARPA.#Internetλ,
pkr@λSU-AI.ARPA.#Internetλ,
qian@λSU-SCORE.ARPA.#Internetλ,
rac@λSU-AI.ARPA.#Internetλ,
rappaport@λSUMEX-AIM.ARPA.#Internetλ,
RDG@λSU-AI.ARPA.#Internetλ,
rennels@λSUMEX-AIM.ARPA.#Internetλ,
rep@λSU-AI.ARPA.#Internetλ,
richer@λSUMEX-AIM.ARPA.#Internetλ,
Rindfleisch@λSUMEX-AIM.ARPA.#Internetλ,
rohn@λSUMEX-AIM.ARPA.#Internetλ,
rosenschein@λSUMEX-AIM.ARPA.#Internetλ,
russell@λSUMEX-AIM.ARPA.#Internetλ,
rww@λSU-AI.ARPA.#Internetλ,
saraiya@λSUMEX-AIM.ARPA.#Internetλ,
sbarnes@λSUMEX-AIM.ARPA.#Internetλ,
scales@λSUMEX-AIM.ARPA.#Internetλ,
selig@λSU-SUSHI.ARPA.#Internetλ,
sg@λSU-AI.ARPA.#Internetλ,
shawn@λSU-SCORE.ARPA.#Internetλ,
shng@λSUMEX-AIM.ARPA.#Internetλ,
Shortliffe@λSUMEX-AIM.ARPA.#Internetλ,
sleeman@λSUMEX-AIM.ARPA.#Internetλ,
smith@λSUMEX-AIM.ARPA.#Internetλ,
Su-bboard@λSU-SCORE.ARPA.#Internetλ,
Subramanian@λSUMEX-AIM.ARPA.#Internetλ,
Suwa@λSUMEX-AIM.ARPA.#Internetλ,
takahashi@λSU-AI.ARPA.#Internetλ,
Teach@λSUMEX-AIM.ARPA.#Internetλ,
Terry@λSUMEX-AIM.ARPA.#Internetλ,
theodorou@λSU-SCORE.ARPA.#Internetλ,
tthompson@λSUMEX-AIM.ARPA.#Internetλ,
TOB@λSU-AI.ARPA.#Internetλ,
treitel@λSUMEX-AIM.ARPA.#Internetλ,
tsuji@λSUMEX-AIM.ARPA.#Internetλ,
tthompson@λSUMEX-AIM.ARPA.#Internetλ,
Tu@λSUMEX-AIM.ARPA.#Internetλ,
Turner@λSUMEX-AIM.ARPA.#Internetλ,
unruh@λSUMEX-AIM.ARPA.#Internetλ,
val@λSU-AI.ARPA.#Internetλ,
VGA@λSU-AI.ARPA.#Internetλ,
Vian@λSUMEX-AIM.ARPA.#Internetλ,
vp@λSU-SCORE.ARPA.#Internetλ,
Walker@λSUMEX-AIM.ARPA.#Internetλ,
wallace@λSU-SCORE.ARPA.#Internetλ,
waltzman@λSU-SCORE.ARPA.#Internetλ,
Warren@λSRI-AI.ARPA.#Internetλ,
washington@λSUMEX-AIM.ARPA.#Internetλ,
Welch-road@λSUMEX-AIM.ARPA.#Internetλ,
whitney@λSUMEX-AIM.ARPA.#Internetλ,
Wiederhold@λSUMEX-AIM.ARPA.#Internetλ,
wilkins@λSUMEX-AIM.ARPA.#Internetλ,
wulfman@λSUMEX-AIM.ARPA.#Internetλ,
yan@λSU-SCORE.ARPA.#Internetλ,
ym@λSU-AI.ARPA.#Internetλ,
yue@λSU-SCORE.ARPA.#Internetλ
Message-ID: <12156662207.75.GINSBERG@SUMEX-AIM.ARPA>
∂04-Nov-85 1607 ACUFF@SUMEX-AIM.ARPA Symbolics shuffling and installation
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 16:07:42 PST
Date: Mon 4 Nov 85 16:06:39-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Symbolics shuffling and installation
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12156667068.26.ACUFF@SUMEX-AIM.ARPA>
Due to hardware limitations (ie. short cables), 3674 has been
moved to the other end of the line of cubicles. Then new 3640
should 74's old spot tomorrow, if all goes well. It isn't clear when
the 3640 will be ready to be used, however, since it will probably
have 6.1, and otherwise take a lot of time to get synced with the
other Symbolics.
74 persists in its network problems, so beware. I'm trying to get
some likely boards swapped.
-- Rich
-------
∂04-Nov-85 1618 SJG change to SIGlunch mailing list
To: "@TOTALS.DIS[1,SJG]"@SU-AI.ARPA
I apologize for the previous message. The content was intended to be the
following:
I have received several inquiries recently regarding the new policy to
send SIGlunch messages only to members of the KSL. This is, I fear,
a pretty hard and fast rule, since we are trying to make these meetings
a bit smaller and more informal. (But everyone is still welcome ...)
The only exceptions I am prepared to make are for SIGlunch speakers.
So, if you want to hear about the SIGlunches, come and give one!
Matt Ginsberg
∂04-Nov-85 1651 ullman@su-aimvax.arpa more papers received today
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 16:50:48 PST
Received: by su-aimvax.arpa with Sendmail; Mon, 4 Nov 85 16:46:06 pst
Date: Mon, 4 Nov 85 16:46:06 pst
From: Jeff Ullman <ullman@diablo>
Subject: more papers received today
To: nail@diablo
"Safety and compilation of non-recursive Horn clauses," by Zaniolo
"On the implementation of a simple class of logic queries for
databases," by Sacca and Zaniolo
∂04-Nov-85 1702 ullman@su-aimvax.arpa paper received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 16:31:34 PST
Received: by su-aimvax.arpa with Sendmail; Mon, 4 Nov 85 16:27:01 pst
Date: Mon, 4 Nov 85 16:27:01 pst
From: Jeff Ullman <ullman@diablo>
Subject: paper received
To: nail@diablo
"Recognizing Pseudo-recursion in deductive databases,"
by Chomicki and Imielinski
Jeff N. need not quake. They dwell on typed formulas, not
untyped as he does. In fact, this paper seems to relate
both to the Maier/Ullman/Vardi "revenge of the JD" (not referenced)
and Sagiv's "real revenge of the JD" (referenced).
Anybody want copies?
---Jeff U.
∂04-Nov-85 1703 REGES@SU-SCORE.ARPA lunch reminder
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 16:43:21 PST
Date: Mon 4 Nov 85 16:39:34-PST
From: Stuart Reges <REGES@SU-SCORE.ARPA>
Subject: lunch reminder
To: faculty@SU-SCORE.ARPA
Office: Margaret Jacks 210, 497-9798
Message-ID: <12156673059.34.REGES@SU-SCORE.ARPA>
Even though Nils is out of town, we will still have a faculty lunch tomorrow
starting at 12:15. I have invited Mary Lou Allen, the director of the Stanford
Instructional Television Network, to come and discuss TV with us. I believe
she plans to share some of her ideas about satellite hookups and other possible
future directions of the network. I'm sure she will be willing to discuss any
issues surrounding TV as well. I hope you can all attend.
-------
∂04-Nov-85 1720 @SU-SCORE.ARPA:WINOGRAD@SU-CSLI.ARPA Forum speakers
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 17:20:21 PST
Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Nov 85 17:21:15-PST
Date: Mon 4 Nov 85 17:19:21-PST
From: Terry Winograd <WINOGRAD@SU-CSLI.ARPA>
Subject: Forum speakers
To: faculty@SU-SCORE.ARPA, csl-faculty@SU-SIERRA.ARPA
cc: tajnai@SU-SCORE.ARPA
The following is the list of speakers suggested to date, as far as I
know. If your entry does not correspond to what you think it should be,
let me know by the end of this week. A "??" following a name means I
got no response. It will transform into a "nobody" by next week unless
told otherwise. This is the proposal list, and everyone on it may not
end up speaking. Also there have been some special sessions (e.g., a KSL
open house) suggested, yet to be worked into the schedule. --t
------------
Binford
Jean Ponce; new Research Associate
David Chelberg
Jitendra Malik
Ron Fearing
Michael Lowry: update
Buchanan - David Wilkins
Cheriton - Ross Finlayson
Feigenbaum - ??
Floyd - ??
Flynn - Chad Mitchell
Genesereth - Jeff Finger
Gill - ??
Golub - ??
Hennessy - Anant Agarwal
Horowitz - Himself (new faculty)
Knuth - Scott Kim
Lantz - ??
Linton - ??
Luckham - ??
Manna - Nobody
Mayr - ??
McCarthy - Ian Mason
McCluskey - ??
Nilsson - ??
Oliger - Christina Fraley, Wei-Pai Tang
Owicki - nobody
Papadimetriou - Joe Mitchell, Esther Arkin, Vlad Rutenberg
Pratt - ??
Reid - ??
Rosenbloom - ??
Shortliffe - Glenn Rennels
Ullman -
Allen Van Gelder
Anna Karlin
Jeff Naughton
Kathy Morris
Ungar - Himself (new faculty)
Tobagi - separate session?
Yitzhak Birk
Hemant Kanakia
M. Mehdi Nassehi, Fouad A. Tobagi and Michel E. Marhic
David Shur
James Storey
Randy Neff
Wiederhold - Winslett, Pednault?
Winograd - nobody
Yao - nobody --------
-------
∂04-Nov-85 2019 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Talk on semantics of types in computer languages
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 20:12:08 PST
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 4 Nov 85 20:09:04-PST
Date: 04 Nov 85 1937 PST
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: Talk on semantics of types in computer languages
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
Speaker: Professor Giuseppe Longo, visiting CSLI from Pisa
Title: The semantics of types and terms and their equivalences
for various lambda-calculi
Time: Wednesday, November 6th, 12 noon
Place: Ventura Conference Room.
Abstract: Lambda calculus provides the core of functional programming
as it is based on the key notions of functional abstraction and
application. The first part of the lecture will present an will
present an introductory account of the main type disciplines and their
semantics. First-order polymorphism and its motivations are also
surveyed. In the second part, the semantic equivalence of typed terms
will be discussed. The relation between types and terms gives us an
insight into second-order polymorphism (parametric types) and its
semantics.
∂04-Nov-85 2048 @SU-CSLI.ARPA:dirk@SU-PSYCH Psychology Department Friday Seminar.
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 20:47:53 PST
Received: from SU-PSYCH by SU-CSLI.ARPA with TCP; Mon 4 Nov 85 20:45:31-PST
From: dirk@SU-PSYCH (Dirk Ruiz)
Received: from by SU-PSYCH with TCP; Mon, 4 Nov 85 20:45:08 pst
Date: 04 Nov 85 20:44:59 PST (Mon)
To: friends@su-csli.ARPA
Subject: Psychology Department Friday Seminar.
Our speaker this week is Gyorgy Gergely. Time and place are 3:15, Friday
(November 8, 1985) in room 100 of Jordan Hall. Title and abstract follow:
------------------------------------------------------------------------
Discourse Integrational Processes in Sentence Comprehension
Gyorgy Gergely
Classical models of sentence processing (e.g., Fodor, Bever & Garrett,
1974) developed in the universalist framework of Chomskian generative
grammar are examined critically from a functionalist comparative
perspective. It is argued that earlier interpretations of on-line measures
of clausal processing (e.g., of the local increase of processing load
before the clause-boundary) lose their plausibility when considering a
class of languages that are typologically radically different from English.
Several experiments will be reported that examine clausal processing in
Hungarian, a non-Indo-European language, which, unlike English, has a)
`free' word order, b) marks underlying structural roles of NPs locally
unambiguously by case-marker suffixes, and c) encodes the discourse
functions of surface constituents syntactically.
The experiments demonstrate the existence of several kinds of discourse
integrational processes (such as `topic foregrounding' or focus-based
`inferential priming') which determine on-line measures of clausal
processing. The results suggest that the local increase in processing load
at the end of the clause serves, to a large extent, across-clause discourse
integrational functions rather than within-clause functions of assigning
underlying structural representations, as previously supposed. It is shown
that, during on-line processing, discourse segmentational cues, identifying
the informational focus (i.e., `new' information) and topic (i.e., `given'
information) of the clause, play a crucial role in directly mapping surface
sequences onto discourse representational structures.
------------------------------------------------------------------------
------- End of Forwarded Message
∂04-Nov-85 2138 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu POPL 86
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 21:37:47 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Mon 4 Nov 85 21:37:23-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Mon 4 Nov 85 21:37:27-PST
Received: by rsch.wisc.edu; Mon, 4 Nov 85 23:01:08 CST
Received: from crys.wisc.edu by rsch.wisc.edu; Mon, 4 Nov 85 14:55:19 CST
Message-Id: <8511042056.AA28603@crys.wisc.edu>
Received: from CS.COLUMBIA.EDU by crys.wisc.edu; Mon, 4 Nov 85 14:56:22 CST
Date: Mon 4 Nov 85 15:47:27-EST
From: "Debra A. Jenkins" <JENKINS@CS.COLUMBIA.EDU>
Subject: POPL 86
To: theory@CRYS.WISC.EDU
Cc: galil@CS.COLUMBIA.EDU
Status: RO
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 04 Nov 85 23:00:40 CST (Mon)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
THIRTEENTH ANNUAL ACM SYMPOSIUM
ON
PRINCIPLES OF PROGRAMMING LANGUAGES
SPONSORED BY ACM SIGACT AND SIGPLAN
JANUARY 13-15, 1986
TRADE WINDS
SAINT PETERSBURG BEACH, FLORIDA
PREREGISTRATION FORM
ACM POPL 86
Fill in and mail to: Dr. Jerald Schwarz
AT&T
190 River Road, Rm. E-330
Summit, N.J. 07901
By Jan. 1 After Jan. 1
ACM and SIGACT or SIGPLAN member $155←←← $215←←←
Either ACM or SIG member........ 165←←← 225←←←
Nonmember....................... 190←←← 250←←←
Student......................... 40←←← 60←←←
Name............................................................
Affiliation.....................................................
Address.........................................................
................................................................
................................................................
Telephone.......................................................
Payment must be in the form of a check made payable to ``ACM POPL 86
Symposium''. No vouchers, purchase orders, or credit cards can be
accepted. Requests for refunds received before January 1, 1986, will
be honored.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
HOTEL RESERVATION FORM
ACM POPL 86
Fill in and mail to: Trade Winds
5500 Gulf Blvd.
St. Petersburg Beach, Florida 33706
Phone: 1-800-237-0707 or 813-367-6461
Reservations must be made before December 23, 1985, after which
requests will be on a space-available basis. Children under 18 in
parent's room stay free.
Accomodations desired: Dates:
←←←single or double at $58.95 Arrival..........
←←←additional person at $5.00 each Departure........
Name........................................................
Affiliation.................................................
Address.....................................................
............................................................
............................................................
To guarantee for late arrival after 2 pm enclose check for one night
payable to ``Trade Winds'', or use (circle) one of American Express,
Diner's Club, Carte Blanche, Master Card, or Visa.
Card No......................... Exp. Date..................
Bank # if Master Card.......................................
POPL 86 PROGRAM
Session 1: Monday, Jan. 13. 9:00 - 10:30
Chair: Charles N. Fischer, Univ. of Wisconsin---Madison
Remote Attribute Updating for Language-Based Editors, T. Reps, Univ.
of Wisconsin---Madison; C. Marceau and T. Teitelbaum, Cornell Univ.
Dynamically Bypassing Copy Rule Chains in Attribute Grammers,
R. Hoover, Cornell Univ.
Global Storage Allocation in Attribute Evaluation, H. Sasaki and T.
Katayama, Tokyo Institute of Technology
Session 2: Monday Jan. 13, 11:00 - 12:30
Chair: Charles N. Fischer, Univ. of Wisconsin---Madison
Finding the Source of Type Errors, M. Wand, Northeastern Univ.
A Maximum Flow Approach to Anomaly Isolation in Unification-Based
Incremental Type Inference, J. A. Walz, Cornell Univ.: G. F. Johnson,
Univ. of Maryland
Hierarchical VLSI Design Systems Based On Attribute Grammars, L. G.
Jones and J. Simon, Pennsylvania State Univ.
Session 3: Monday, Jan. 13, 2:00 - 3:30
Chair: Steven S. Muchnick, Sun Microsystems
Code Motion of Control Structures in High Level Languages, K. Zadeck,
R. Cytron and A. Lowry. IBM T. J. Watson Research Center, Yorktown
Heights, New York
Compilers and Staging Transformations, U. Jorring and W. L. Scherlis,
Carnegie-Mellon Univ.
A Set-Theoretic Characterization of Function Strictness in the Lambda
Calculus, P. Hudak and J. Young, Yale University
Session 4: Monday, Jan. 13, 4:00 - 6:00
Chair: Robert Henry, Univ. of Washington
Retargetable High-Level Alias Analysis, D. S. Coutant,
Hewlett-Packard, Cupertino, California
High-Quality Code Generation Via Bottom-Up Tree Pattern Matching, P.
J. Hatcher and T. W. Christopher, Illinois Institute of Technology
A Parallel Language and Its Compilation to Multiprocessor Machines or
VLSI, M. Chen, Yale Univ.
REPORT FROM THE PROGRAM COMMITTEE
Survey/Tutorial: Tuesday, Jan. 14, 8:15 - 9:00
To be announced
Session 5: Tuesday, Jan. 14, 9:00 - 10:30
Chair: Fred B. Schneider, Cornell Univ.
Towards Programming with Knowledge Expressions, R. KurkiSuonio,
Tampere Univ. of Technology, Finland
Limitations of Synchronous Communication with Static Process Structure
in Languages for Distributed Computing, B. Liskov, M.I.T.; M. Herlihy,
C.M.U.; L. Gilbert, Autographix Inc.
Atomic Data Abstractions in a Distributed Collaborative Editing
System, I. Grief, R. Seliger and W. Weihl, M.I. T.
Session 6: Tuesday, Jan. 14, 11:00 - 12:30
Chair: Fred B. Schneider, Cornell Univ.
A Really Abstract Concurrent Model and Its Temporal Logic, H.
Barringer and R. Kuiper, Univ. of Manchester, England; A. Pneuli,
Weizmann Institute of Science, Isreal
Expressing Interesting Properties of Programs in Propositional
Temporal Logic, P. W@olper, AT&T Bell Laboratories
Operational Semantics of a Parallel Object-Oriented Language, P.
America, Philips Research Laboratories, The Netherlands; J. de Bakker,
J. N. Kok and J. Rutten, Centre for Mathematics and Computer Science,
Amsterdam, The Netherlands
Session 7: Tuesday, Jan. 14, 2:00 - 3:30
Chair: Michael O'Donnell, Univ. of Chicago
Equational Logic Programming: An Extension to Equational Programming,
J. You, Univ. of Utah; ,P. A. Subrahmanyam, AT&T Bell Laboratories
Logic Programming and Inheritance, H. Ait-Kaci and R. Nasr,
Microelectronmics and Computer Technology Corp., Austin, Texas
Unification in Many-Sorted Algebras as a Device for Incremental
Semantic Analysis, G. Snelting and W. Henhapl, Technische Hochshule
Darmstadt, West Germany
Session 8: Tuesday, Jan. 14, 4:00 - 5:30
Chair: Peter Weinberger, AT&T Bell Laboratories
Distributed Data Structures in Linda, N. Carriero, D. Gelernter and J.
Leichter, Yale University
Para-Functional Programming: A Paradigm for Programming Multiprocessor
Systems, P. Hudak and L. Smith, Yale Univ.
Annotations for Distributed Programming in Logic, R. Ramakrishnan and
A. Silberschatz, Univ. of Texas
Survey/Tutorial: Wednesday, Jan. 15, 8:15 - 9:00
To be announced
Session 9: Wednesday, Jan. 15, 9:00 - 10:30
Chair: Dexter Kozen, Cornell University
Representation Independence and Data Abstraction, J. C. Mitchell, AT&T
Bell Laboratories
Using Dependent Types to Express Modular Structure: Experience with
Pebble and ML, D. B. MacQueen, AT&T Bell Laboratories
`Type' Is Not a Type, A. R. Meyer and M. B. Reinhold, M. I. T.
Session 10: Wednesday, Jan. 15, 11:00 - 12:30
Chair: Steven S. Muchnick, Sun Microsystems
Data Flow Analysis of Applicative Programs Using Minimal Function
Graphs, N. D. Jones, DIKU, Denmark; A. Mycroft, Cambrdige Univ.,
England
A Mechanically Certified Theorem About Optimal Concurrency of Sorting
Netwroks, C. Huang and C. Lengauer, Univ. of Texas at Austin
Executable Specifications with Quantifiers in the FASE System, S.
Jefferson and S. Kamin, Univ. of Illinois at Urbana-Champaign
GENERAL INMFORMATION
POPL 86
Location
The Thirteenth Annual ACM Symposium on Principles of Programming
Langauges, sponsored by ACM SIGACT and SIGPLAN, will be held January
13-15 (Monday - Wednesday) 1986, at the TradeWinds Resort, 5500 Gulf
Blvd., St. Petersburg Beach, Florida 33706. A limousine service -
Limo - provides transportation 24 hours a day from Tampa International
Airport to the conference sight, approximately 30 miles away. Go to
the booth just outside the baggage claim area. Cost about $9.50.
By car, take I-75 to I-275 and south the St. Petersburg, exiting at
Pinellas Bayway to St. Petersburg Beach and Eckerd College. Continue
across the Bayway to St. Petersburg Beach, at Gulf Blvd. ( the end of
the Bayway) turn right (north); the conference site is about one mile
on the left at the TradeWinds.
Accomodations
A block of rooms is reserved at the TradeWinds for POPL attendees.
All reservations must be made prior to December 23, 1985, either by
using the attached reservation form or by telephoning 800-237-0707 or
813-367-6461. In the latter case you must mention that you will be
attending the ACM POPL symposium to get the conference rate.
Registration
The regular registration rates include two lunches, the reception
Sunday Evening January 12 from 8:00 pm to 10:00 pm, the dinner-cruise
on Tuesday, coffee breaks, and a copy of the proceedings. The student
rate includes only the reception on Sunday, the coffee breaks, and a
copy of the proceedings. The facilties for social functions will be
selected on the basis of the number of advance registrations ; there
is a possibility that some of the social functions will not have room
for you if you do not pre-register. Registration fees rise by $60 on
January 1, 1986.
Conference Organization
Conference Co-Chairs: Mark Scott Johnson and Ravi Sethi: Program
Chair: Charles N. Fischer; Treasurer; Jerald Schwarz; Local
Arrangements: Edmund Gallizzi, Eckerd College, P. O. Box 12560, St.
Petersburg, FL 33733, 813-867-1166 ext. 272 .
About the Location
The TradeWinds is a resort on St. Petersburg Beach directly on the
Gulf of Mexico. It has a breezy tropical ambiance, pools, saunas,
whirlpools, fully equipped exercise room, tennis and outdoor
racquetball courts, all beach and water sports, including sailing,
windsurfing, and windsurfing lessons. Temperatures in January rabge
from the high 70's to the low 50's. People go in the ocean all year
round.
Excursion
After the sessions on Tuesday, buses will take people from the hotel
to the Capt. Anderson for a three hour inland water cruise, including
live band and a sit-down dinner.
-------
-------------
TN Message #7
-------------
∂04-Nov-85 2213 @SU-SUSHI.ARPA:broder@decwrl.DEC.COM BATS at DEC - November 22
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 22:13:43 PST
Received: from decwrl.DEC.COM by SU-SUSHI.ARPA with TCP; Mon 4 Nov 85 22:12:47-PST
Received: from magic.ARPA (magic) by decwrl.DEC.COM (4.22.01/4.7.34)
id AA06338; Mon, 4 Nov 85 22:13:02 pst
Received: by magic.ARPA (4.22.01/4.7.34)
id AA14992; Mon, 4 Nov 85 22:12:36 pst
From: broder@decwrl.DEC.COM (Andrei Broder)
Message-Id: <8511050612.AA14992@magic.ARPA>
Date: 4 Nov 1985 2212-PST (Monday)
To: aflb.all@su-sushi
Cc:
Fcc: sent
Subject: BATS at DEC - November 22
DEC-SRC in Palo Alto will host the next Bay Area Theory Seminar on
November 22. Mark your calendar and spread the word. I will post the
schedule (and maybe even the lunch menu) in about one week.
- Andrei
∂05-Nov-85 0046 DAVIES@SUMEX-AIM.ARPA No AAP meeting Wednesday
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 00:45:54 PST
Date: Tue, 5 Nov 1985 00:47 PST
Message-ID: <DAVIES.12156761908.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: No AAP meeting Wednesday
Due to the lack of a speaker, there will be no Architecture Project
meeting this week. A volunteer is eagerly sought for next week.
-- Byron
∂05-Nov-85 1148 BERG@SU-SCORE.ARPA technical reports
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 11:45:14 PST
Date: Tue 5 Nov 85 11:43:43-PST
From: Kathy Berg <BERG@SU-SCORE.ARPA>
Subject: technical reports
To: faculty@SU-SCORE.ARPA, ras@SU-SCORE.ARPA
cc: berg@SU-SCORE.ARPA
Stanford-Phone: (415) 497-4776
Message-ID: <12156881346.33.BERG@SU-SCORE.ARPA>
In the interest of providing faster service, and to better anticipate
the space and resource needs of the publications office, I would like
to have some idea of the number of research papers that will be
submitted over the next two or three months.
If you are planning to have technical reports published, please
let me know the number of reports you will be preparing, and
the approximate number of pages of each report.
My thanks for your kind attention to this request.
Kathryn Berg
-------
∂05-Nov-85 1438 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 14:38:03 PST
Received: from ames-vmsb.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Nov 85 14:36:06-PST
Date: 4 Nov 85 18:57:00 PST
From: welch@ames-vmsb.ARPA
Subject: SIGBIG
To: super@su-score.arpa
Reply-To: welch@ames-vmsb.ARPA
ASSOCIATION FOR COMPUTING MACHINERY
San Francisco Golden Gate Chapter
"SIGBIG" Special Interest Committee
For Large High Speed Computers
Meetings on the first Wednesday of each month at 7:30 PM. Speakers
who can give insights to various aspects of SUPERCOMPUTING are
featured each month.
Next meeting:
Wednesday, November 6,1985, 7:30 PM
Topic: Performance Measurement for High Speed Systems: A Panel
Location: Evans Hall Room 608-7
University of California Berkeley
Directions: Just North of the Campanile (belltower)
at East entrance of campus.
Panel:
E. Miya, NASA Ames Research Center
F. McMahon, LLNL
D. Bailey, Informatics General Corp, NASA ARC
K. Rowley, NASA Ames Research Center
Metrics and tools of measuring high speed systems are critical for
determining the characteristics of large systems. There are no agreed
upon measures: Whetstones, Dhrystones, MIPS, MFLOPS, LOPS, LIPS,
and many more. Current strategies include: running an arbitrary
set of operations which "characterises" [from the English] a job mix,
a sets of kernels or fundamental primitives used in scientific
calculation, just running existing code, or specialized tests
for functional units (vector), or just running a single subroutine
in as identical an environment as possible like the Dongarra benchmark.
Problems exist in characterizing the complete system versus portions
of a system, measurement strategies and design methodologies, to adding
multiple processors. Three of the speakers will cover some of the better
known benchmarking programs: the Livermore Loops and the newer NAS
vector kernels. A fourth panel member will discuss a new approach to
performance measurement.
---------------------------------------------------------------
Tape-recordings of most of the previous may be obtained
in exchange for a tape cassette or $5.00 by contacting:
Mary Fowler (415)261-4058 (rec)
Supercomputing #192, BOX 2787
Alameda, CA. 94501-0787
For information contact Mary Fowler, Chairperson (415) 839-6547
or Mike Austin, Publ. Chair (415) 423-8446
------
∂05-Nov-85 1519 LIBRARY@SU-SCORE.ARPA Socrates: Searching By Call Number In The Technical Reports File
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 15:19:19 PST
Date: Tue 5 Nov 85 15:18:40-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: Searching By Call Number In The Technical Reports File
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA,
: ;
Message-ID: <12156920477.17.LIBRARY@SU-SCORE.ARPA>
The Technical Reports file has a call number index. The accession numbers
we assign to Math/CS technical reports are in this index. However if you
wish to search by our accession number it must always be a six digit number.
Therefore if the report you are looking for is number 18203 you need to
search by the number 018203. Report number 9405 should be searched with
009405.
We will be investigating the possibility of dropping the leading 0's.
I would be interested to know if anyone finds it useful to be able to
search by our accession number. Under what circumstances would you
have the accession number and not an author and title?
Harry Llull
-------
∂05-Nov-85 1543 LIBRARY@SU-SCORE.ARPA Socrates: How to Telnet--A Reminder
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 15:42:26 PST
Date: Tue 5 Nov 85 15:42:12-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: How to Telnet--A Reminder
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12156924761.17.LIBRARY@SU-SCORE.ARPA>
To use Socrates from your departmental computers you can telnet for
forsythe. First you give the command telnet. Telnet> Forsythe.
Then when you receive -- login: -- type Forsythe again. login: Forsythe.
When you receive "enter class" type 20 and hit the return when it says
"class start". When you use your Socrates account number and password to
login it will take you autormatically into Socrates.
If you don't have a Socrates account or an ITS account, you need to come
to the Math/CS Library to fill out a form for a Socrates account.
H. Llull
-------
∂05-Nov-85 1551 LIBRARY@SU-SCORE.ARPA Socrates: Telnet message correction
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 15:51:30 PST
Date: Tue 5 Nov 85 15:46:10-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: Telnet message correction
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12156925481.17.LIBRARY@SU-SCORE.ARPA>
When you telnet there is no need to enter 20 for class. This is done
automatically. When using a Gandalf you do need to enter class 20.
HL
-------
∂05-Nov-85 1620 @SU-SCORE.ARPA:EVAN@SU-CSLI.ARPA Re: Socrates: Searching By Call Number In The Technical Reports File
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 16:20:43 PST
Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Nov 85 16:11:22-PST
Date: Tue 5 Nov 85 16:09:01-PST
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Re: Socrates: Searching By Call Number In The Technical Reports File
To: LIBRARY@SU-SCORE.ARPA
cc: su-bboards@SU-SCORE.ARPA, faculty@SU-SCORE.ARPA, evan@SU-CSLI.ARPA
In-Reply-To: Message from "C.S./Math Library <LIBRARY@SU-SCORE.ARPA>" of Tue 5 Nov 85 15:26:03-PST
I actually have used this feature. The circumstances were that I had done
a search and jotted down the numbers of the 10 or so reports that looked
promising. When I went to the shelves, one of them was gone and three of
them were in boxes. I then went back to Socrates with the call numbers
(all I had written down) to get more info so that I could look to see if
the reports had been published elsewhere (two had).
evan
-------
∂05-Nov-85 1632 @SU-SCORE.ARPA:EVAN@SU-CSLI.ARPA Last Message (an apology)
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 16:32:51 PST
Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Nov 85 16:12:56-PST
Date: Tue 5 Nov 85 16:10:39-PST
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Last Message (an apology)
To: faculty@SU-SCORE.ARPA, su-bboards@SU-SCORE.ARPA
That was just supposed to go to the Library. I really have to change
my default from REPLY ALL.
evan
-------
∂05-Nov-85 1748 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #27
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 17:47:47 PST
Date: 5 Nov 85 1741-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #27
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 6 Nov 1985 Volume 1 : Issue 27
Today's Topics:
Second PARSYM Survey: Data Abstractions for Parallel Programming
----------------------------------------------------------------------
Date: Tue, 5 Nov 1985 17:39 PST
From: DAVIES@SUMEX-AIM.ARPA
Subject: Second PARSYM Survey
Now that replies to the survey have tapered off, I offer summaries of
some other work involving data abstractions for parallel computing.
The Actors model provides a very general data abstraction for parallel
computing: the actor. The Connection Machine notion of a xector
provides a powerful representation of aggregations of data for SIMD
computation. Neither of these concepts is strictly a data
abstraction. I think this is endemic to parallel computing: our data
abstractions need to be closely linked to the processes that compute
with them. Both actors and xectors involve aspects of processing.
Actors also incorporate a powerful form of message-passing for
communication.
ACTORS
Dan Theriault, in his MIT thesis, discusses actors as data
abstractions (among other things):
The actor model of computation is one in which many active,
self-contained computing entities, called actors, process
communications in parallel. Each actor has its own
processing power and storage. Instead of having a notion of
control flow, the actor model makes use of a more flexible
idea of cooperation -- communication among entities which
are under their own control. Actors interact by
transmitting information in "communications" to each other.
An actor cannot directly view or manipulate the contents or
implementation of another actor. All it can do is
communicate with the actor, asking it for information or
requesting it to change. Only the actor itself can alter
its behavior. This property is know by several names,
including representation abstraction, protrection,
encapsulation, opacity, and information-hiding. ...
In addition to being opaque, an actor is entirely
self-contained. It can only communicate with its
acquaintances and with the acquaintances of the
communication it is processing. There is no notion of global
state to put restrictions on the existence and location of
the actor. ...
Actors' properties of representation abstraction and
absolute containment suggest the modularity inherent in the
actor model. The model goes beyond this, unifying data,
control, and procedural abstractions. [Since] an
actor contains both data and procedural information (its
acquaintances and script), [it] is ... sufficient for
representing both procedures and data structures. The
model's emphasis on communication blurs the distinction
between them.
Each actor has a set of acquaintances with whom it may communicate.
The acquaintance relationships between actors determine the topology
of the actor system. The set of acquaintances of an actor may be
static or may change dynamically. Actors may be composed
hierarchically: that is, an arbitrary network of communicating actors
may be packaged up as a single actor.
A list may be represented by a linked collection of actors (i.e.,
conses) each of which has two acquaintances, its car and its cdr, and
responds to two messages, CAR and CDR. A pipeline of processes may be
represented by a collection of actors, each with one acquaintance.
Each pipeline element receives messages and does some processing
(executes its "script"), sending a message to its acquaintance.
A thesis by Gul Agha presents the Actors philosophy and explains why
Actors are a powerful mechanism for describing and implementing
concurrent processes on distributed computers.
References:
Gul A. Agha: Actors: A Model of Concurrent Computation in
Distributed Systems, MIT AI Lab Technical Report 844, March
1985.
Daniel G. Theriault: Issues in the Design and Implementation of Act2,
MIT EECS Thesis, 1983.
XECTORS
From "The Connection Machine":
Connection Machine Lisp (CmLisp) is an extension of Common
Lisp, designed to support the parallel operations of the
Connection Machine. ... In CmLisp, as in the Connection
Machine itself, parallelism is achieved through simultaneous
operations over composite data structures rather than
through concurrent control structures.
...
All concurrent operations in CmLisp involve a simple data
structure called a xector (pronounced zek'tor). A xector
corresponds roughly to a set of processors with a value
stored at each processor. Because a xector is distributed
across many processors, it is possible to operate on all its
elements simultaneously. To add two xectors together, for
example, the Connection Machine directs each processor to
add the corresponding values locally, producing a third
xector of the sums. This requires only a single addition
time, even though the xector may have hundreds of thousands
of elements.
CmLisp supports many potentially concurrent operations to
combine, create, modify, and reduce xectors. These
operations could be implemented on a conventional computer,
but they would be much slower, perhaps tens of thousands of
times slower, than they are on the Connection Machine.
CmLisp also allows the programmer to define new xector
operations that execute concurrently. This is the source of
its power.
To CmLisp, the world is composed of collections of thousands of slaves who
will carry out commands. Xectors make it easy to describe groups
of slaves. This is quite different from the Actors view. To Actors,
the world is composed of many independent agents, each negotiating
with the others rather than commanding them.
The book gives a more complete description of the Connection Machine,
CmLisp, xectors as computational objects (to be read, printed,
operated upon, operated with) and a version of DEFSTRUCT for describing
xector entries.
In a chapter titled "Data Structures for the Connection Machine",
Hillis introduces "active data structures", a combination of data
structure and processor optimized for specific tasks. In particular,
Hillis describes active versions of sets, trees, strings, arrays,
matrices, and graphs, all of which can be implemented as xectors. For
example, the active version of a string contains a character per
processor. Searching for a string S1 within another string S2 takes
time proportional to the length of S1. On the first cycle, the first
character of S1 is used as a probe. Each matching character cell in
S2 activates its successor in the string. The successors are probed
to see if they match the second character in S1 and so on. Since each
cycle happens in constant time, the search time is proportional to the
length of S1. (What is the constant of proportionality? What is the
appropriate cycle time for the Connection Machine, and how does it
scale with the total number of cells in the Connection Machine?)
Hillis's book is a masterpiece. Beg, borrow, or steal it, or better
yet, buy it, but READ IT.
References:
W. Daniel Hillis: The Connection Machine. MIT Press, 1985.
------------------------------
End of PARSYM Digest
********************
∂05-Nov-85 1914 ullman@su-aimvax.arpa meeting tomorrow
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 19:14:28 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 5 Nov 85 19:11:24 pst
Date: Tue, 5 Nov 85 19:11:24 pst
From: Jeff Ullman <ullman@diablo>
Subject: meeting tomorrow
To: nail@diablo
Shuky will discuss the Kanellakis/Cosmodakis paper.
Meet at 11AM in 301 MJH.
∂05-Nov-85 2305 ACUFF@SUMEX-AIM.ARPA 3640 setup and ready for use
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 23:05:27 PST
Date: Tue 5 Nov 85 23:06:40-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: 3640 setup and ready for use
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12157005671.29.ACUFF@SUMEX-AIM.ARPA>
KSL-3640-7 (also 3647 and 7) is now ready for use. Its console
is located where 3674 used to be. It has a very small disk, so there
is only one band (release 6.0 with IP and Vt100), and swapping; no
file space. Enjoy, and let me know if it has problems...
-- Rich
-------
∂06-Nov-85 0631 PATASHNIK@SU-SUSHI.ARPA AFLB abstracts
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 06:30:55 PST
Date: Wed 6 Nov 85 06:32:02-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: AFLB abstracts
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12157086748.13.PATASHNIK@SU-SUSHI.ARPA>
Here are abstracts for the next two AFLBs:
**************************************
7-Nov-85 : Alejandro A. Sch\"affer (Stanford)
Shortest Prefix Strings Containing All
k-Element Permutations as Subsequences
What is the length of the shortest string consisting of elements of
{1,...,n} that contains as subsequences all permutations of any
$k$-element subset? Many authors have considered the special case
where k=n. In fact, this special case was posed by D.E. Knuth
(attributed to R. M. Karp) as problem 36 in the technical report
STAN-CS-72-292. This problem arose in analyzing shortest path
algorithms and flowgraph reduction algorithms.
I shall instead consider an incremental variation on the problem first
proposed by P.J. Koutas and T.C. Hu (Discrete Math. 11(1975) pp.
125-132). For a fixed value of n they ask for a string on the
alphabet {1,...,n} such that for all values of k <= n, the prefix
containing all permutations of any k-element subset as subsequences is
as short as possible. The problem can also be viewed as follows. For
k = 1 one needs n distinct digits to find each of the n possible
permutations. In going from k to k + 1, one starts with a string
containing all k-element permutations as subsequences, and one adds as
few digits as possible to the end of the string so that the new string
contains all k+1-element permutations. The catch is that for all
values of k most shortest prefixes for k cannot be extended minimally
to prefixes for k+1.
Until now only very weak results were known about this version with
the prefix restriction posed by Koutas and Hu. I shall describe an
*exact* solution using only *elementary* techniques.
I intend to make occasional use of the side blackboard in MJH352.
***** Time and place: November 7, 12:30 pm in MJ352 (Bldg. 460) ******
14-Nov-85 : Richard Anderson (Stanford & MSRI)
A Parallel Algorithm for Depth First Search
A new parallel algorithm for constructing a depth first search tree in
an undirected graph will be described. The algorithm is a P-RAM
algorithm and uses several probabilistic algorithms as subroutines.
The run time of the algorithm is 2↑{\sqrt{\log n}}. This makes it an
almost RNC algorithm, since the run time is less than n↑e for any e>0.
The standard sequential algorithm for depth first search can be shown
to be ``inherently sequential'', so this shows that substantial speed
up for depth first search is possible when a different approach is
taken.
***** Time and place: November 14, 12:30 pm in MJ352 (Bldg. 460) ******
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352.
If you have a topic you would like to talk about in the AFLB seminar
please let me know. (Electronic mail: patashnik@su-sushi.arpa, phone:
(415) 497-1787). Contributions are wanted and welcome. Not all time
slots for this academic year have been filled.
More information about future and past AFLB meetings and topics are in
the file [SUSHI]<patashnik.aflb>aflb.bboard .
- Oren Patashnik
-------
∂06-Nov-85 1409 ullman@su-aimvax.arpa paper received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 14:09:44 PST
Received: by su-aimvax.arpa with Sendmail; Wed, 6 Nov 85 14:08:38 pst
Date: Wed, 6 Nov 85 14:08:38 pst
From: Jeff Ullman <ullman@diablo>
Subject: paper received
To: nail@diablo
"The Inconsistency of Relational Database Theory" by
Roger Flynn of Univ. of Pittsburgh.
∂06-Nov-85 1742 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 17:42:27 PST
Date: Wed 6 Nov 85 17:41:42-PST
From: LANSKY@SRI-AI.ARPA
Subject: Next Monday's PLANLUNCH
To: planlunch.dis: ;
MODEL THEORY FOR KNOWLEDGE AND BELIEF
Moshe Vardi
IBM San Jose
11:00 AM, MONDAY, November 11
SRI International, Building E, Room EJ228 (new conference room)
Recently, there has been a surge of interest in the modal logic of
knowledge and belief, which has applications in many area of computer
science. The standard semantics for modal logic is Kripke semantics.
In this semantics, possible worlds and the possibility relation are both
primitive notions. This has both technical and conceptual shortcomings.
From a technical point of view, the mathematics associated with Kripke
semantics is often quite complicated. From a conceptual point of view,
it is not clear how to use Kripke structures to model knowledge and belief,
where one wants a clearer understanding of the notions that are taken as
primitive in Kripke semantics.
We introduce modal structures as models for modal logic. We use the idea
of possible worlds, but by directly describing the internal semantics of
each possible world. It is much easier to study the standard logical
questions, such as completeness, decidability, and compactness, using
modal structures. Furthermore, modal structures offer a much more
intuitive approach to modelling knowledge and belief.
As an application, we present a semantic model for knowledge
with the following properties:
(1) Knowledge is necessarily correct
(2) agents are logically omniscient, i.e., they know all
the consequences of their knowledge
(3) agents are positively introspective, i.e., they are aware of
their knowledge, but not negatively introspective,
i.e., they may not be aware of their ignorance.
We argue that this is the appropriate model for implicit knowledge.
We investigate the properties of the model, and use it to formalize
notions such as "to know more" and "all that is known is".
-------
∂06-Nov-85 2010 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu MFCS '86 Call for Papers
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 20:10:43 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 6 Nov 85 20:09:52-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Wed 6 Nov 85 20:09:26-PST
Received: by rsch.wisc.edu; Wed, 6 Nov 85 21:41:02 CST
Received: from crys.wisc.edu by rsch.wisc.edu; Wed, 6 Nov 85 10:20:35 CST
Message-Id: <8511061620.AA02294@crys.wisc.edu>
Received: from CS.COLUMBIA.EDU by crys.wisc.edu; Wed, 6 Nov 85 10:20:13 CST
Date: Wed 6 Nov 85 11:17:25-EST
From: "Debra A. Jenkins" <JENKINS@CS.COLUMBIA.EDU>
Subject: MFCS '86 Call for Papers
To: theory@CRYS.WISC.EDU
Cc: galil@CS.COLUMBIA.EDU
Status: R
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 06 Nov 85 21:40:45 CST (Wed)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
CALL FOR PAPERS
TWELFTH INTERNATIONAL SYMPOSIUM
MFCS '86
MATHEMATICAL FOUNDATIONS OF COMPUTER SCIENCE
AUGUST 25 - 29, 1986
BRATISLAVA, CZECHOSLOVAKIA
ASSOCIATION OF SLOVAK MATHEMATICIANS AND PHYSICISTS
SLOVAK ACADEMY OF SCIENCES
The International Symposium on Mathematical Foundations of Computer Science
MFCS '86
is the twelfth in the series of MFCS symposia organized in
Czechoslovakia and Poland. The aim of the these symposia is to bring
together specialists in theoretical fields of computer science from
various counntries and to stimulate mathematical research in
theoretical computer science.
Principle areas of interest include:
- algorithms and data structures
- models of computation
- complexity and computability theory
- automata and formal langauges
- theory of logical design and layout of VLSI systems
- parallel and distributed computing
- semantics and logic of programs
- cryptography
- theory of data bases and knowledge based systems
- theory of robotics and artificial intelligence
This is not intended to be an exhaustive list.
Then scientific program of the symposium will include
- invited lectures covering areas of current interest
- short communications describing original research
The proceedings of the symposium will be available at the meeting.
LOCATION AND TIME
The symposium will be held in Bratislava, on August 25 - 29, 1986
SYMPOSIUM CHAIRMAN
Branislzav Rovan
ORGANIZING SECRETARY
Juraj Hromkovic
MAILING ADDRESS OF THE ORGANIZING COMMITTEE
MFCS '86
Department of Theoretical Cybernetics
Komensky University
Mlysnka dolina
842 15 Bratislava
Czechoslovakia
Telephone:320 003
ORGANIZING COMMITTEE
J. Bocek, A. Cerny, Z. Durayova, J. Gruska,
J. Hromkovic, S. Hudak, E. Kubincova,
P. Mikulecky, B. Rovan /chairman/ P. Ruzicka,
H. Stefanova, J. Wiederman
COOPERATING INSTITUTIONS
Komensky University, Bratislava
Institute of Technical Cybernetics of
the Slovak Academy of Sciences, Bratislava
VUSEI-AR, Bratislava
Purkyne University, Brno
Safarik University, Kosice
Charles University, Prague
Slovak Technical University, Bratislava
-------------
Please, use the attached REPLY CARD for a preliminary information to
the organizers and return it at your earliest convenience.
The number of participants is limited.
SUBMISSION OF PAPERS
Authors are invited to submit six copies of a full draft paper of the
size of 7-15 LNCS-like pages in English to the chairman of the Program
Committee BY JANUARY 15, 1986
Too short /long/ submissions risk that the Program Committee will not
be able to fully appreciate their merit because of the lack of
information /time/
Authors will be notified of acceptance or rejection on APRIL 1, 1986
The final text of accepted papers, typed on special forms, is due by
MAY 15, 1986
PROGRAM COMMITTEE
A. Adachi /Tokyo/
G. Aussiello /Rome/
E. Borger /Dortmund/
L. Budach /Berlin/
J. W. de Bakker /Amsterdam/
A. P. Ershov /Novosibirsk/
R. Freivalds /Riga/
T. Gergely /Budapest/
J. Gruska /Bratislava/ -chairman
I. Guessarian /Paris/
P. Hajek /Prague/
M. Nivat /Paris/
T. Ottmann /Karlsruhe/
F. P. Preparata /Urbana/
H. Rasiowa /Warsaw/
B. Rovan /Bratislava/
A. Salomaa /Turku/
I. H. Sudborough /Evanston/
J. van Leeuwen /Utrecht/
E. Wagner /Yorktown Heights/
W. Wechler /Dresden/
J. Wiedermann /Bratislava/ - secretary
D. Wood /Waterloo/
CHAIRMAN OF THE PROGRAM COMMITTEE
Jozef Gruska
MFCS '86
Institute of Technical Cybernetics
Slovak Academy of Sciences
Dubravska 9
842 37 Bratislava
Czechoslavakia
Telephone: 375 000 Telex: 093355 tkasav
REPLY CARD MFCS '86
Name←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←Ms/Mr/Dr/Prof
Address←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Telephone: Telex:
Yes No
←←← ←← I wish to attend the symposium. Please send me further
details and the registration form.
←←← ←← I wish to submit a paper. Its provisional title or subject.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
I expect to be accompanied by ←←←←←←←←←←←←←persons.
-------
-------------
TN Message #8
-------------
∂08-Nov-85 1647 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 12 (R. Wilensky, UCB)
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 8 Nov 85 16:47:06 PST
Received: from ucbvax.berkeley.edu by SU-CSLI.ARPA with TCP; Thu 7 Nov 85 19:32:59-PST
Received: by ucbvax.berkeley.edu (5.31/1.2)
id AA16621; Thu, 7 Nov 85 17:27:35 PST
Received: by cogsci (5.31/5.13)
id AA04733; Thu, 7 Nov 85 17:29:20 PST
Date: Thu, 7 Nov 85 17:29:20 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8511080129.AA04733@cogsci>
To: cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Nov. 12 (R. Wilensky, UCB)
BERKELEY COGNITIVE SCIENCE PROGRAM
Cognitive Science Seminar - IDS 237A
Tuesday, November 12, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``Knowledge Representation and a Theory of Meaning''
Robert Wilensky
Computer Science Division, U.C.B.
Knowledge representation is central to most Artificial Intelli-
gence endeavors. However, most knowledge representation
schemes are incomplete in a number of ways. In particular,
their coverage is inadequate, and they do not capture signifi-
cant aspects of meanings. Many do not even adhere to basic
criteria of well-formedness for a meaning representation.
KODIAK is a theory of knowledge representation developed at
Berkeley that attempts to address some of these deficiencies.
KODIAK incorporates representational ideas that have emerged
from different schools of thought, in particular from work in
semantic networks, frames, Conceptual Dependency, and frame
semantics. In particular, KODIAK eliminates the frame/slot
distinction found in frame-based languages (alternatively,
case/slot distinction found in semantic network-based systems).
In its place KOKIAK introduces a new notion called the
absolute/aspectual distinction. In addition, the theory sup-
ports ``non-literal'' representations, namely, those motivated
by metaphoric and metonymic considerations. Using these dev-
ices, the theory allows for the representation of some ideas
that in the past have only been represented procedurally,
informally, or not at all.
KODIAK is being used to represent both linguistic and concep-
tual structures. When applied to the representation of
linguistic knowledge, a new framework for talking about meaning
emerges. Five aspects of meaning have been identified. These
appear to be useful in describing processing theories of
natural language use.
----------------------------------------------------------------
UPCOMING TALKS
November 19: Richard Alterman, Computer Science, UCB
November 26: Eve Clark, Linguistics, Stanford
December 3: Bernard Baars, Langley Porter, UCSF
----------------------------------------------------------------
ELSEWHERE ON CAMPUS
Peter Pirolli will speak on ``Intelligent Tutoring Systems'' at
the SESAME Colloquium on November 18, 2515 Tolman Hall, 4:00pm.
∂08-Nov-85 1649 @SU-CSLI.ARPA:barwise.pa@Xerox.ARPA "Machines and the mental"
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 8 Nov 85 16:49:05 PST
Received: from Xerox.ARPA by SU-CSLI.ARPA with TCP; Fri 8 Nov 85 09:11:26-PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 NOV 85 09:10:04 PST
Date: 8 Nov 85 08:58 PST
From: barwise.pa@Xerox.ARPA
Subject: "Machines and the mental"
To: Folks@SU-CSLI.ARPA
cc: Newsletter@SU-CSLI.ARPA
Message-ID: <851108-091004-1300@Xerox>
For complicated reasons, my TINLunch has been moved from Dacember to
next Thursday. As a result, no abstract appeared in yesterday's
newsletter. Here is one:
"Machines and the mental" by Fred Dretske
The paper argues that current computers do not exhibit anything that
deserves to be called rational cognitive activity. Dretske even claims
that they can't add! He then goes on to discuss how one might build
something that deserves to be called a rational machine.
This short, well-written paper is Dretske's Presidential Address to the
APA. Read it can come prepared for a lively session.
∂08-Nov-85 1704 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #28
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 8 Nov 85 17:03:28 PST
Date: 8 Nov 85 0034-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #28
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Friday, 8 Nov 1985 Volume 1 : Issue 28
Today's Topics:
Automated Reasoning on the Cray
Actors = Smalltalk?
Seminars: SPUR - Symbolic Processing Using RISCs (IBM San Jose)
----------------------------------------------------------------------
Date: Wednesday, 30 October 1985 18:16-PST
From: Bruce Smith <unc!bts%unc.csnet at CSNET-RELAY.ARPA>
(copied without permission from "Association of Automated
Reasoning Newsletter No. 5")
Automated Reasoning on the CRAY
(from W. McCune)
The automated reasoning system ITP was recently ported
to the CRAY X-MP-22 at the National Magnetic Fusion Energy
Computer Center in Livermore, California. NMFECC has its
own operating system (CTSS), but the standard CRAY Research
Pascal compiler was used. On a set of five benchmark
problems, speedups from a VAX 11/780 running Berkeley UNIX
4.2 to the CRAY ranged from 5.8 to 9.4. This performance is
especially disappointing, considering that the Berkeley UNIX
Pascal compiler does not generate fast code.
The following factors may explain the poor performance;
all are related to the fact that CRAYs are designed for
numeric computation. First, the non-numeric sequential
computation of ITP cannot make use of the vectorization or
multitasking capabilities of the CRAY. Second, the stack-
based execution required by the use of Pascal is rumored to
cause a slowdown of 2. Finally, it seems likely that the
CTSS operating system does not use sophisticated techniques
for managing dynamically allocated memory.
This experience supports the argument that there is a
need for ultra-high-performance hardware and software
tailored specifically for symbolic computing.
[Similar results have been reported with PSL (Portable Standard Lisp)
and the Gabriel benchmarks on the Cray (sorry, no reference handy, but
the work was done at Los Alamos, I believe). With PSL, no vector
processing was attempted, so only the scalar speed mattered. The Cray
is a whizbang processor, but it wasn't designed for Lisp. The same
problem will undoubtedly apply to many other parallel architectures as
well. Who's designing a multiprocessor Lisp machine? -- BD]
------------------------------
Date: 7 Nov 1985 17:34:18-EST
From: linus!brando@mitre-bedford.ARPA
With all due respect to those involved, isn't the whole Actors
paradigm essentially at one with object-oriented paradigms a la
Smalltalk, which have been around for quite some time now? It seems
as if little more has been done than to change the names to protect
the innocent. I don't mean to be provocative in any way -- I'm very
interested in finding out what differentiates these 2 ways of doing
business, other than using different terms to describe essentially the
same concepts.
Thom
[Objects -- from Smalltalk or even earlier from Simula -- were
certainly a motivation for Actors (see Carl Hewitt's early papers).
Unlike Smalltalk or Simula, Actors have additional features to support
distributed multiprocessing, including a buffered communication
network and distributed resource management. In addition, the Actor
model is supported by an impressive foundation of philosophy and
theory, demonstrating in particular that the Actor model is strictly
more powerful than (some) other competing models of parallel
computing.
Would any Actor folks care to comment further? -- BD]
------------------------------
Date: 8 Nov 1985 00:34:18-PST
From: Byron Davies <DAVIES@SUMEX-AIM.ARPA>
Re: Seminars at IBM San Jose
Tues., Nov. 5 Computer Science Seminar
2:00 P.M. SPUR - SYMBOLIC PROCESSING USING RISCS
Aud. A We describe the architecture of a multiprocessor
risc workstation under development at
University of California, Berkeley. Each
processor consists of a custom VLSI CPU, an
integrated cache controller/memory management
unit, and a floating point co-processor. The
processor includes architectural support for
Common LISP, the cache controller implements a
hardware multiprocessor cache coherency scheme,
the memory management unit performs high
performance virtual memory translation without a
TLB, and the floating point unit implements the
I.E.E.E. standard. Six faculty and twenty
students are involved in the project, which
spans from i.c. design to programming
environments research. The project is being
supported by DARPA under the Strategic Computing
Initiative.
R. Katz, Computer Science Division,
University of California, Berkeley
Host: L. Cabrera
Thurs., Nov. 7 Computer Science Seminar
2:00 P.M. THE SPRITE NETWORK OPERATING SYSTEM
Aud. B Sprite is a new network operating system built
by a team of graduate students and myself as
part of the SPUR workstation project. The talk
will focus on three parts of Sprite: the
filesystem, process offloading, and the virtual
memory system. The filesystem will provide a
single shared Unix-like file hierarchy
distributed across several servers. Clients
will use dynamically-constructed prefix tables
to associate file names with servers. Sprite
will include a process offloading mechanism that
allows jobs to be run on idle workstations in
the same way that jobs may be placed in
background in Unix. The virtual memory system
will be Unix-like with simple extensions to
permit shared data segments and synchronization.
I'll talk about how changes in technology have
influenced the design of Sprite and try to
convince you that a) a simple network filesystem
eliminates the need for other network protocols,
RPC, name servers, and the like; b) magnetic
disks will soon be obsolete; and c) paging is
also about to be obsolete (sort of).
J. Ousterhout, Computer Science Division,
University of California, Berkeley
Host: L. Cabrera
------------------------------
End of PARSYM Digest
********************
∂08-Nov-85 1826 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 8 Nov 85 18:26:15 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Fri 8 Nov 85 18:24:50-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Fri 8 Nov 85 18:24:43-PST
Received: by rsch.wisc.edu; Fri, 8 Nov 85 20:00:59 CST
Message-Id: <8511090018.AA28827@rsch.wisc.edu>
Received: from IBM-SJ.ARPA (ibm-sj.csnet) by rsch.wisc.edu; Fri, 8 Nov 85 18:18:21 CST
Date: 8 Nov 85 16:19:07 PST
From: FAGIN@IBM-SJ.ARPA
To: theory@rsch.wisc.edu
Status: R
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 08 Nov 85 20:00:36 CST (Fri)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
IBM San Jose Research has a new home, about 5 miles from our
old Research Lab. Our new name is the IBM Almaden Research
Center. Our new lab has been built on 690 acres in the
Almaden Valley of San Jose, only 40 acres of which are being
developed. Since our Computer Science Department will be
moving November 22-25, 1985, the purpose of this note is to
give you the new phone numbers and addresses of the
theoreticians in our department. You can start using the
new address right away (the mail will be forwarded, if
needed), and you should use the new phone numbers starting
Monday, November 25.
Ajtai, Miklos (408) 927-1784 Department K53/801
Backus, John (408) 927-1848 Department K53/803
Dwork, Cynthia (408) 927-1752 Department K55/801
Fagin, Ron (408) 927-1726 Department K53/801
Friedman, Joel (408) 927-1807 Department K53/801
Halpern, Joe (408) 927-1787 Department K53/801
Klawe, Maria (408) 927-1714 Department K53/801
Lucas, Peter (408) 927-1847 Department K52/802
Malachi, Yoni (408) 927-1885 Department K52/803
Megiddo, Nimrod (408) 927-1786 Department K53/801
Munshi, Ash (408) 927-1808 Department K54/802
Peleg, David (408) 927-1790 Department K53/801
Pippenger, Nick (408) 927-1727 Department K51/801
Rissanen, Jorma (408) 927-1813 Department K54/802
Shedler, Gerry (408) 927-1783 Department K53/801
Simons, Barbara (408) 927-1785 Department K53/801
Skeen, Dale (408) 927-1755 Department K55/801
Stockmeyer, Larry (408) 927-1789 Department K53/801
Strong, Ray (408) 927-1758 Department K55/801
Upfal, Eli (408) 927-1788 Department K53/801
Vardi, Moshe (408) 927-1781 Department K55/802
Wilber, Robert (408) 927-1791 Department K53/801
Williams, John (408) 927-1888 Department K53/803
Wimmers, Ed (408) 927-1882 Department K53/803
(Note: Wolfgang Paul, who is now in physics, will not be
moving to the new lab for months).
The address (where you should, of course, supply the
appropriate department number) is:
Department K53/801
IBM Almaden Research Center
650 Harry Road
San Jose, California 95120-6099
The CSNET/ARPANET address is usually lastname@ibm-sj (for
example, Fagin@ibm-sj). There are a few exceptions: for
example, Wolfgang Paul is Wolfgang@ibm-sj, Nick Pippenger is
Nicholas@ibm-sj, Larry Stockmeyer is Stock@ibm-sj, Eli Upfal
is Ely@ibm-sj. We are now directly on Arpanet, so you don't
need to use Csnet-Relay. The BITNET/VNET address is, for
example, FAGIN at ALMVMA (with the same exceptions).
-------------
TN Message #9
-------------
∂08-Nov-85 1829 admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 12 (R. Wilensky, UCB)
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 8 Nov 85 18:28:49 PST
Received: by ucbvax.berkeley.edu (5.31/1.2)
id AA16621; Thu, 7 Nov 85 17:27:35 PST
Received: by cogsci (5.31/5.13)
id AA04733; Thu, 7 Nov 85 17:29:20 PST
Date: Thu, 7 Nov 85 17:29:20 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8511080129.AA04733@cogsci>
To: cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Nov. 12 (R. Wilensky, UCB)
BERKELEY COGNITIVE SCIENCE PROGRAM
Cognitive Science Seminar - IDS 237A
Tuesday, November 12, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``Knowledge Representation and a Theory of Meaning''
Robert Wilensky
Computer Science Division, U.C.B.
Knowledge representation is central to most Artificial Intelli-
gence endeavors. However, most knowledge representation
schemes are incomplete in a number of ways. In particular,
their coverage is inadequate, and they do not capture signifi-
cant aspects of meanings. Many do not even adhere to basic
criteria of well-formedness for a meaning representation.
KODIAK is a theory of knowledge representation developed at
Berkeley that attempts to address some of these deficiencies.
KODIAK incorporates representational ideas that have emerged
from different schools of thought, in particular from work in
semantic networks, frames, Conceptual Dependency, and frame
semantics. In particular, KODIAK eliminates the frame/slot
distinction found in frame-based languages (alternatively,
case/slot distinction found in semantic network-based systems).
In its place KOKIAK introduces a new notion called the
absolute/aspectual distinction. In addition, the theory sup-
ports ``non-literal'' representations, namely, those motivated
by metaphoric and metonymic considerations. Using these dev-
ices, the theory allows for the representation of some ideas
that in the past have only been represented procedurally,
informally, or not at all.
KODIAK is being used to represent both linguistic and concep-
tual structures. When applied to the representation of
linguistic knowledge, a new framework for talking about meaning
emerges. Five aspects of meaning have been identified. These
appear to be useful in describing processing theories of
natural language use.
----------------------------------------------------------------
UPCOMING TALKS
November 19: Richard Alterman, Computer Science, UCB
November 26: Eve Clark, Linguistics, Stanford
December 3: Bernard Baars, Langley Porter, UCSF
----------------------------------------------------------------
ELSEWHERE ON CAMPUS
Peter Pirolli will speak on ``Intelligent Tutoring Systems'' at
the SESAME Colloquium on November 18, 2515 Tolman Hall, 4:00pm.
∂09-Nov-85 0513 VONHENKE@SRI-CSL.ARPA RISKS-1.22
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 9 Nov 85 05:13:24 PST
Date: Fri 8 Nov 85 23:58:10-PST
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSL.ARPA>
Subject: RISKS-1.22
Sender: VONHENKE@SRI-CSL.ARPA
To: RISKS-LIST@SRI-CSL.ARPA
RISKS-LIST: RISKS-FORUM Digest Wednesday, 16 Oct 1985 Volume 1 : Issue 22
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Friedrich von Henke, guest moderator
Contents:
Administratrivia (Friedrich von Henke)
Medical software incidents (Nancy Leveson)
European activities (Udo Voges)
Robots are different (Jerry Saltzer)
Automobile computer control systems (Bennett Smith)
Police computers (Dave Dyer)
Electronic Surveillance (Geoffrey S. Goodfellow / Bill Keefe)
Network Mailer Woes (Lynne Moore)
Databases, grades, etc. (Karl Kluge, Andy Mondore, Mark Sienkiew)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions should
be relevant to the topic, technically sound, objective, in good taste, and
coherent. Others will be rejected. Diversity of viewpoints is welcome.
Please try to avoid repetition of earlier discussions.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Subject: Administratrivia
From: Friedrich von Henke (vonHenke@SRI-CSL)
I am temporarily acting as guest moderator of the Risks Forum.
Peter Neumann had to go rather abruptly on an overseas trip, and
the transition happened a bit disorderly. My apologies to all of
you who were eagerly awaiting their twice-weekly cost of RISKS readings
but had to go without. I hope to have things under control now.
Apparently the hiatus has had the effect of slowing down the stream of
contributions to a merely trickle; please don't hesitate to get the flow
going again!
Friedrich von Henke
----------------------------------------------------------------------
Date: 11 Oct 85 19:39:27 PDT (Fri)
From: Nancy Leveson <nancy@UCI-ICSD.ARPA>
To: RISKS@sri-csl.ARPA
Subject: medical software incidents
I was just on a panel concerned with Software Safety at an IEEE
conference on Computers in Medicine and heard about some more
incidents involving software faults.
The first was cited in a recent RISKS forum message (about the
programmable implanted pacemaker which was inadvertently reprogrammed by
emitted magnetic fields from an anti-theft device in a retail store),
but the patient
was cited as having survived. Unfortunately, his weakened heart was
unable to stand the increased pace, and he died.
Other recalls by the FDA involve:
1) An infusion-pump (used for insulin) had a software problem which
caused the infusion of insulin or dextrose to be delivered at the
maximum rather than the lower intended rate. This occurred when certain
valid data was entered according to user instructions.
2) A programmable pacemaker "locked-up" when being reset by an
external programming device. Luckily this occurred in a doctor's office,
and the doctor was able to revive the patient.
3) A multiple-patient monitoring system was recalled because the software
got patients' names mixed up with the wrong data.
4) An algorithm was incorrectly programmed in a diagnostic lab instrument
which caused certain patient data to be reported erroneously as all zeros.
The reference for these incidents (for those who want to quote them) is:
H. Bassen, J. Silberberg, F. Houston, W. Knight, C. Christman, and
M. Greberman. "Computerized Medical Devices: Usage Trends, Problems,
and Safety Technology," in Proc. 7th Annual Conference of IEEE
Engineering in Medicine and Biology Society, Sept. 27-30, 1985,
Chicago, Illinois, pp. 180-185.
Nancy Leveson
University of Calif. Irvine
------------------------------
Date: Fri, 11 Oct 85 11:38:57 PDT
From: Udo Voges <voges@LOCUS.UCLA.EDU>
To: RISKS@SRI-CSL.ARPA
Subject: European activities
I would like to bring some activities to your attention which are
going on in Europe, especially within and triggered by EWICS TC 7.
The European Workshop on Industrial Computer Systems (EWICS), TC on
Systems Reliability, Safety and Security (TC 7) is working since about
10 years in this area, having some 100 members from industry, research
and university. Previous work resulted in Position Papers on
Development of safety related software
Hardware of safe computer systems
Guidelines for verification and validation of safety related software
Guidelines for documentation of safety related computer systems
Techniques for verification and validation of safety related software
System requirements specification for safety related systems
Current working areas include:
System integrity
Software quality assurance and metrics
Design for system safety
Reliability and safety assessment
Besides conducting about four working meetings a year the TC is organizing
the IFAC/IFIP Workshop on Achieving Safe Real-Time Computer Systems
(Safecomp'79, '82, '83, '85, '86).
The results of the work of TC 7 are introduced into the standardisation
process (IEC, ISO, and national bodies) as well as used by companies
and licensing authorities.
Those interested in more information can either contact me or the
current Chairman of TC 7: Mr. J.M.A. Rata, Electricite de France,
1 Avenue du General de Gaulle, F-92141 CLAMART FRANCE.
There exists an American counterpart to EWICS TC 7, but it was not
possible to attract enough interested persons to keep it alive.
The Japanese counterpart is also active, but due to the language
barrier communication is minimal.
Udo
------------------------------
Date: Sat, 12 Oct 85 01:30 EDT
From: Saltzer@MIT-MULTICS.ARPA
Subject: Robots are different
To: risks@SRI-CSL.ARPA
When someone gets pinned to the wall by a robot, something different is going
on as compared to when someone gets gunned down by an FBI agent operating
under incorrect information retrieved from the NCIC. Both cases may lead to
specific tragedies, yet the example of risks from robots seems to me to be
qualitatively different from many other computer-use risks.
The difference is that robots are used primarily in environments where
mechanically-oriented people are accustomed to balancing the risks of new
machinery against the benefits. These people have, over the years, learned to
deal with risks from gear trains and drive belts, from swinging tailends on
steamshovels, from runaway elevators, from inadequately supported cranes.
They watch out, they learn from accidents, their insurers offer advice, they
make mistakes and take risks, and they learn. To a first approximation, an
industrial robot presents a risk similar in kind to other new machinery, and
there is a moderately well-working system in place that is accustomed to
watching for the risks. If anything, the average mechanic is suspicious of a
new piece of machinery in direct proportion to its complexity, newfangledness,
and gadgetry level, so is probably expecting the robot to screw up in
marvelous ways. One might wish to argue with the particular balance that an
industry has struck between risks and benefits, but it is unusual to find one
in which mechanical risks are not understood at least moderately well.
The mechanic's suspicion of the new gadget is the essence of what seems to be
missing in many other applications of computers, and why it is so important to
raise awareness of the need to assess risks. I'm not convinced we need to
harass our colleagues in the robot business with risk-consciousness-raising.
We should be instead talking to their installers to find out what we can
learn.
Jerry Saltzer
------------------------------
Date: Wed, 23 Oct 85 11:14:29 -0100
From: ircam!bks@seismo.CSS.GOV (Bennett Smith)
To: NEUMANN@SRI-CSL.ARPA
Subject: Automobile computer control systems susceptible to interference
By chance I saw an article in an issue of the
"Journal of Environmental Engineers" (published in England, date of
issue about 10 months ago, I believe) about the sensitivity of
a microprocessor-controlled automobile control system to external
electromagnetic radiation. As I recall, a CB transmitter near the car
could, at the right frequency, make the engine slow down or speed up.
Perhaps this article would interest some of your contributors.
Bennett Smith
IRCAM
31, Rue Saint Merri
75004 Paris, France {seismo,philabs,decvax}!mcvax!ircam
------------------------------
Date: 15 Oct 1985 23:42:01 PDT
Subject: The human element
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: risks@SRI-CSL.ARPA
The human element really is where the action is, and it is
a completely two-edged sword; Human actions which have the
power to "fix" something almost inherently also give the power
to "break" things equally severely. Conversely, weighty
check and balance systems intended to prevent abuse end up
preserving the status quo, however good or bad that may be.
The "police computer horror story" I'm most familiar
with is illustrative. This is a well documented case
I've been reading about in ACLU publications.
It seems some poor soul had his wallet stolen, and some criminal
adopted his identity and later was involved in a robbery/murder.
Through some circumstances peculiar to the case, the stolen
identity, but not the culprit, were known to the LAPD. The
detectives working on the case put the stolen identity into
a national police computer. Our hero was stopped for
a routine traffic citation, the computer coughed his
name up, and he ended up on ice for a few days as a
murder suspect.
So far, this is pretty harmless and understandable. Eventually
the guy's identity and and non-involvement were establishd and
he was turned loose. Then it happened again. And Again.
The guy began carrying a letter from the local chief of police,
saying he wasn't the guy the computer said was wanted, but
that didn't cut it when he traveled.
The problem was that the LAPD detectives who put in the
original "want" refused to remove it. Eventually the
guy (and the ACLU) got the courts to mandate expunging
the computer. I think the detectives involved and the
LAPD are being sued. Quite rightly.
The point is, it is <<hard>> to design a system that
can do its intended job, permit discovery and correction
of errors, and resist unautherized or inappropriate use.
I can't imagine a system that can do all three.
------------------------------
Date: 24 Oct 1985 11:17-PDT
Subject: Electronic Surveillance.
From: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>
[forwarded to RISKS by Bill Keefe <keefe%milrat.DEC@decwrl.DEC.COM>
from TELECOM Digest Volume 5, Issue 55, October 24, 1985]
Americans' Privacy Exposed by New Technology, Congress Told
By LEE BYRD - Associated Press Writer
WASHINGTON (AP) - The explosion in communications technology has so
outpaced privacy laws that Americans have little or no protection
against a plethora of new ways for government or private adversaries
to pry into their lives, a congressional agency reported today.
The non-partisan Office of Technology Assessment found that 35 out
of 142 domestic federal agencies use or plan to use various
electronic surveillance methods, including modern devices not
governed by a landmark 1968 law that circumscribed the use of
wiretaps and bugs - concealed microphones.
The agency said 36 agencies, not counting those in foreign
intelligence, already use a total of 85 computerized record systems
for investigative or intelligence purposes, and maintain 288 million
files on 114 million people. The report raised the ''technically
feasible'' specter of these being linked into a single data base
network that could track untold numbers of citizens without due
cause.
The report, requested by House and Senate committees, noted that
many new and uncontrolled methods of surveillance are made possible
by the very technologies of which more and more Americans are
availing themselves - electronic mail, computer conferencing,
cellular and cordless telephones, beepers and electronic pagers.
Intercepting such devices is easy, and ''the law has not kept pace,''
the agency said.
But other devices, such as miniature television cameras and pen
registers - which monitor the numbers called on a given telephone
line - have enabled new ways to spy on people even if their own
communications habits are more old-fashioned, the agency noted.
Rep. Robert W. Kastenmeier, D-Wis., chairman of the House Judiciary
subcommittee on courts and civil liberties, said the study ''shows
how the law in this area has broken down; it is up to Congress to fix
it. If we fail to act, the personal and business communications of
Americans will not have the privacy protection they deserve.''
Sen. Charles McC. Mathias, R-Md., said the report ''documents how
new and more intrusive forms of snooping have followed in the wake of
the exciting advances in communications technology,'' and agreed
Congress must ''bring federal privacy laws up to date.'
Rep. Don Edwards, D-Calif., chairman of the House Judiciary
subcommittee on civil and constitutional rights, said, ''While the
attorney general of the United States is claiming that the civil
liberties granted by the Constitution should be limited to the
'original intentions' of the framers, the technological possibilities
for government surveillance have exploded. The framers knew nothing
of closed-circuit television, wiretapping and computer data banks.''
The report noted that the Fourth Amendment, which protects ''the
right of the people to be secure in their persons, houses, papers and
effects, against unreasonable searches and seizures,'' was written
''at a time when people conducted their affairs in a simple direct,
and personalized fashion.''
Neither, said the report, has Title III of the Crime Control and
Safe Streets Act of 1968, which was designed to protect the privacy
of wire and oral communications, kept pace.
''At the time Congress passed this act,'' the report said,
''electronic surveillance was limited primarily to simple telephone
taps and concealed microphones. Since then, the basic communications
infrastructure in the United States has been in rapid technological
change.''
The congressional agency said it could not estimate the extent of
electronic surveillance in the private sector, saying only ''it is
probable that many forms ... go undetected, and if detected, go
unreported.''
But in its survey of the federal bureaucracy, OTA found 35 agencies,
mostly in the Justice, Treasury and Defense departments, used or
planned to use:
-Closed circuit television, 29 agencies.
-Night vision systems, 22.
-Miniature transmitters, 21.
-Electronic beepers and sensors, 15.
-Telephone taps, recorders, and pen registers, 14.
-Computer usage monitoring, 6.
-Electronic mail monitoring, 6.
-Cellular radio interception, 5.
-Satellite interception, 4.
As for the 85 computerized record systems that could be used for
surveillance purposes, none of the operators provided statistics
requested by the OTA on record completeness and accuracy.
Under the 1968 law, wiretaps and bugs are prohibited without a court
order based on the affirmation of a high-ranking prosecutor that a
crime has occurred, that the target of the surveillance is involved,
and that other means of investigation would be ineffective.
According to the Administrative Office of the U.S. Courts, federal
and state judges approved 801 out of 802 requests last year for
electronic surveillance, primarily wiretaps and hidden microphones,
at an average cost of $45,000.
The agency said that while there is some promise in emerging
techniques for low-cost data encryption or other means to protect
communication systems from eavesdropping, ''there is no immediate
technological answer ... against electronic surveillance.''
Foreign intelligence cases are governed by a separate law, so the
CIA, National Security Agency and Defense Intelligence Agency were
not included in the survey.
------------------------------
Date: 0 0 00:00:00 CDT [sic! ed.]
From: "UV2::MOOREL" <moorel@uv2.decnet>
Subject: Network Mailer Woes...
To: "risks" <risks@sri-csl>
In a recent issue of one of the digests on the net, there was a problem
mentioned that seems to have a bearing on risks on computer systems, particu-
larly as use of computer networking increases in the future. At their request,
the names have been changed to preserve anonymity.
Apparently for the past month, the people who reside on the
bitnet have been unable to receive [this digest]. There is a long
story behind this [...]. This story is also a *lot*
of guesswork as to what happened.
At the beginning of September, [our system] changed its host
name to conform to the new domain name standards. The site we
were using to get to bitnet, did not recognize the new name and
began rejecting all mail from [our system]. We did not become
aware of this because we were not receiving any rejections or errors
back from the gateway. We were however, receiving mail *from* the
people on Bitnet who were asking what happened to their [...] digest.
We attempted to contact the people at [the gateway] but of
course the mail failed and they never did anything to correct the
problem which they, of course, were not aware of because nobody was
complaining. (Sounds like a Catch-22 situation if I ever heard
one).
In any case, the problem has now been resolved.
Unfortunately, these people have missed close to 50 digests. There
is no way I can tie up the mailer at [either the host or the gateway]
in order to remail the messages. I also understand that there is no
way to use FTP from the bitnet.
It appears that several incidents conspired together to cause the loss of this
information, and although the loss was not critical, it will take much time and
effort for the people involved to catch up. If this had been a more critical
information transfer, it might have been corrected faster; however, there is a
good chance that it would have gone undetected anyway. It seems to be one more
reason for information about any potential changes to be passed on to any sites
that may be affected and to be thoroughly checked on both ends to prevent this
kind of thing from reoccurring.
Lynne C. Moore (Moorel@Eglin-Vax.Arpa)
------------------------------
From: Karl.Kluge@G.CS.CMU.EDU
To: risks@sri-csl.arpa
Subject: Grade changing.
Some doubt has been expressed in this forum recently about people
changing grades and living happily ever after. I can't talk about
college systems, but in high school all the grades, attendence, etc.
for my high school and several other high schools were kept on a
mainframe in a centralized location. There is a system in Michigan
called MOIS for vocational data, and on the back of my MOIScript on
computer science was the transcript of a terminal session between the
attendance people and the computer. The login message gave the phone
number of the mainframe. The password was overprinted, but that is
useless -- you can learn to read through almost any overprinting.
Access to the grading, course scheduling, and attendance programs was by
providing a social security number which was echoed and not overprinted.
I thus found myself able to do really miraculous things. Being sixth in
my high-school class, I had no real motivation to use my knowledge
maliciously, and informed the administration. Some safeguards were added
(old social security numbers retired, certain social security numbers
only giving access to certain programs, restricting access to certain
programs to certain accounts), but I'm sure those could have been
circumvented with minimal effort -- I was a fairly good systems hack on
the operating system, and there were people who could hack rings around
me. The operating system was a simple three-tier ring system, and a lot
of the features put in for the sake of usability made it very insecure.
I send this to give first-hand evidence to those who have been posting
doubts that such things happen.
------------------------------
Date: Wed, 16 Oct 85 17:11:36 EDT
From: Andy←Mondore%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
To: RISKS@sri-csl.arpa
Subject: Databases, grades, etc.
One of the systems programmers here at RPI made a point about
administrators and students sharing the same computer: You
really aren't that much more secure when you have administrators
and students on separate computers if there is a network or dial-up
connection to the administrative computer than you are when
administrators and students are on the same computer. If you have
network or dial-up connections to an administrative computer, it
isn't too difficult for a student with an autodial modem to write
a program on a PC that simply tries all possible phone numbers
for certain telephone exchanges and record the numbers that
produce a carrier tone. Then the student could have another
program that tries passwords unless the system disconnects the
line after a certain number of unsuccessful tries. The major
advantage of separating administrators and students is that
it might be more difficult for a student to access an administrative
file from a student account assuming the administrative file has the
proper protection set.
------------------------------
Date: Mon, 21 Oct 85 0:44:24 EDT
From: Sienkiew@louie.udel.EDU
To: risks@louie.udel.EDU
Subject: Database, Grades, etc...
You can create an extremely effective audit trail if you think about it for a
while. That just makes the problem more "challenging".
Suppose you do your auditing one day and find that there were unauthorized
grade changes made for every student in the CS department and 1/2 of them
requested (incorrect) printed transcripts. It seems unlikely that everybody
independently broke in on the same day. So who do you penalize? How many
transcripts have been mailed out already?
Suppose no grades were changed but there is a trojan horse waiting to raise
the grade only under certain circumstances?
My point is that the data doesn't have to stay changed forever. And you can't
check the auditing records for every transaction, if you expect to gain by
using the computer. You need to do as much as you can, of course, but beware
of the false sense of security...
Mark.
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂09-Nov-85 1516 ACUFF@SUMEX-AIM.ARPA More Explorer info
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Nov 85 15:16:15 PST
Date: Sat 9 Nov 85 15:17:03-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: More Explorer info
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12157968758.74.ACUFF@SUMEX-AIM.ARPA>
I've produced a short document "Explorers for KSL D-machine Users",
filed in Sumex:<LispM>Exp-for-D.*, and placed copies by all the pool
Explorers and X11. It briefly comments on what a D-machine user
trying to use and Explorer should know to transfer expertise.
Also, the first thing anyone should do when using an Explorer for
the first time is to run the function (NEW-USER) to set up a directory
and initializatoin file.
-- Rich
-------
∂09-Nov-85 1822 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #29
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Nov 85 18:22:05 PST
Date: 9 Nov 85 1757-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #29
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Sunday, 10 Nov 1985 Volume 1 : Issue 29
Today's Topics:
Actors -= Smalltalk
AI on Crays
----------------------------------------------------------------------
Subject: Actors -= Smalltalk
Date: 08 Nov 85 07:29:15 EST (Fri)
From: schwamb@mitre.ARPA
This is in response to linus!brando@mitre-bedford (Thom)
in PARSYM V1 #28.
I think there IS a key distinction between object-oriented paradigms
(a la Smalltalk, Flavors, and the like) and the Actors paradigm. The
Actors approach is designed for the *asynchronous* operation of a set
of computational objects. The object-oriented approaches on the other
hand are inherently synchronous. In fact, implementations such as
Flavors are little more than function application with a level of
indirection (indeed Lisp programmers implemented early versions of
this approach by just attaching a function onto some property of an symbol).
Of course, parallel activity can be simulated in the object-oriented
approach quite nicely, but that's what it is, a simulation. The
Actor model (as Byron Davies pointed out) was designed from the start
with distributed processing in mind. As far as I know, no object-oriented
system is implemented this way. (However, efforts are under way to
look at this, including Lisa Sokol's work at MITRE (Washington).)
This, of course, leads to different uses for message passing in the
two approaches. In object-oriented programming you have a value returned
which is usually another object. You could look at this as the "message
reply". The Actor system has no automatic reply mechanism, and so the
communication is more easily implemented on parallel architectures.
I think an examination of the MIT Memos on Actors, and the ACT series
of languages will make this distinction clearer.
...Karl
------------------------------
Date: Fri, 8 Nov 85 10:04:38 pst
From: eugene@AMES-NAS.ARPA (Eugene Miya)
Subject: AI on Crays
The contact at LANL [Los Alamos National Laboratory] for PSL is Wayne
Anderson. The object of LISP is to run symbolic algebra packages, I
think you can guess which ones. One of our people moved XLISP to the
Cray-2. No one has done any work on vectorizing LISP: how would you
do it? LISP on the Cray is still faster than any LISP out there from
what I understand Anderson and others have told me.
--eugene miya
[Lisp on a Cray is 5-10x a Symbolics 3600, as I remember, while
Fortran on a Cray is 50-100x a VAX 780 on benchmarks of interest to
number hackers. Since a 3600 and a VAX are approximately the same
"power", give or take a factor of 2, we're missing an order of
magnitude somewhere. Is the order of magnitude due to Cray hardware
being inappropriate for Lisp or to the lack of a good Lisp compiler
for the Cray, or some combination? Would a functional subset of Lisp
be appropriate for vectorization? -- BD]
------------------------------
End of PARSYM Digest
********************
∂10-Nov-85 1804 @SU-SCORE.ARPA:JMC@SU-AI.ARPA
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 10 Nov 85 18:03:58 PST
Received: from SU-AI.ARPA by SU-SCORE.ARPA with TCP; Sun 10 Nov 85 18:00:44-PST
Date: 10 Nov 85 1757 PST
From: John McCarthy <JMC@SU-AI.ARPA>
To: faculty@SU-SCORE.ARPA
baby
Carolyn Talcott (McCarthy) and John McCarthy announce the birth
of Timothy Talcott McCarthy on November 9, 1985 at 0022. He
weighed five pounds nine ounces. All are well.
∂10-Nov-85 1916 LANSKY@SRI-AI.ARPA PLANLUNCH reminder -- 11AM Moshe Vardi
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 10 Nov 85 19:16:14 PST
Date: Sun 10 Nov 85 19:17:07-PST
From: LANSKY@SRI-AI.ARPA
Subject: PLANLUNCH reminder -- 11AM Moshe Vardi
To: planlunch.dis: ;
MODEL THEORY FOR KNOWLEDGE AND BELIEF
Moshe Vardi
IBM San Jose
11:00 AM, MONDAY, November 11
SRI International, Building E, Room EJ228 (new conference room)
Recently, there has been a surge of interest in the modal logic of
knowledge and belief, which has applications in many area of computer
science. The standard semantics for modal logic is Kripke semantics.
In this semantics, possible worlds and the possibility relation are both
primitive notions. This has both technical and conceptual shortcomings.
From a technical point of view, the mathematics associated with Kripke
semantics is often quite complicated. From a conceptual point of view,
it is not clear how to use Kripke structures to model knowledge and belief,
where one wants a clearer understanding of the notions that are taken as
primitive in Kripke semantics.
We introduce modal structures as models for modal logic. We use the idea
of possible worlds, but by directly describing the internal semantics of
each possible world. It is much easier to study the standard logical
questions, such as completeness, decidability, and compactness, using
modal structures. Furthermore, modal structures offer a much more
intuitive approach to modelling knowledge and belief.
As an application, we present a semantic model for knowledge
with the following properties:
(1) Knowledge is necessarily correct
(2) agents are logically omniscient, i.e., they know all
the consequences of their knowledge
(3) agents are positively introspective, i.e., they are aware of
their knowledge, but not negatively introspective,
i.e., they may not be aware of their ignorance.
We argue that this is the appropriate model for implicit knowledge.
We investigate the properties of the model, and use it to formalize
notions such as "to know more" and "all that is known is".
-------
∂11-Nov-85 0140 RESTIVO@SU-SCORE.ARPA PROLOG Digest V3 #44
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 01:40:16 PST
Date: Saturday, November 9, 1985 1:39PM
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
Reply-to: PROLOG@SU-SCORE.ARPA
US-Mail: P.O. Box 4584, Stanford CA 94305
Phone: (415) 326-5550
Subject: PROLOG Digest V3 #44
To: PROLOG@SU-SCORE.ARPA
PROLOG Digest Monday, 11 Nov 1985 Volume 3 : Issue 44
Today's Topics:
Query - Profiling & Crays,
LP Philosophy - Lisp in Prolog,
Implementation - DCG + Left Recursion
----------------------------------------------------------------------
Date: Sun, 20-Oct-85 20:52:26 PDT
From: (Jonathan Pincus) ernie!pincus@UCB-Vax
Subject: Profiling Programs?
Has anybody out there ever tried to profile a Prolog program?
Specifically, how do I find out how much time various procedures
require? Obviously, I want to do this in order to speed up the
program in the important places (for that matter, does the old
chestnut about 10% of the code requiring 90% of the execution
time hold for Prolog?).
My specific environment is C-Prolog (version 1.2) on a VAX. One
thought that has occurred to me is that timing information needs
to be recorded at the same time that "spy"ing information gets
printed out, but I'm not sure how to do that. Any comments/advice
/solutions will be gratefully accepted, and if anything exciting
turns up I'll post a summary. Please don't tell me "Oh, that's just
an efficiency question, you shouldn't worry about that!"
-- Jon
------------------------------
Date: Wed, 23 Oct 85 10:20:44 edt
From: Carl Landwehr <landwehr@nrl-css.ARPA>
Subject: Prolog for Cray?
I am new to this list, so bear with me if this is an old query.
We have a Cray X-MP that might be available for us to run Prolog,
if we could find a Prolog for it. Does anyone out there have one,
or know of plans to develop one?
-- Carl Landwehr
------------------------------
Date: 23 Oct 85 17:48:09 PDT (Wed)
From: Sanjai Narain <narain@rand-unix.ARPA>
We are about to begin a project which intends to use both
Franzlisp and Prolog IN THE SAME ENVIRONMENT. Are there any
suitable Prologs with efficiency >= 1KLips? We use SUNs and
Vaxes running UNIX. Any leads would be greatly appreciated.
-- Sanjai Narain
------------------------------
Date: Thu, 24 Oct 85 22:14 EDT
From: Hewitt@MIT-MC.ARPA
Subject: Lisp in Prolog?
I would like to reply to the message from William Clocksin which said
... it cannot have escaped the attention of most people that writing
a compiler (in Prolog) to COMPILE Lisp into some target (say LAP)
would be as easy as pie. For those of us who have written
compilers in both Lisp and Prolog, I daresay it would be a lot
easier in Prolog. I might further suggest that the compiler
test is more useful than the interpreter test, and that the
interpreter test has no especial theoretical advantage, since
the compiler can be seen as a meaning-preserving transformation.
(Ahem. Which in fact it isn't for Lisp if you're not careful
with bindings).
I argue that the above compiler is not a very good test of Prolog
because the code produced by the proposed Prolog compiler for
Common Lisp WILL NOT RUN on a standalone Prolog system. Thus the
proposed compiler does not address a fundamental problem which is
the LACK OF EXPRESSIVE CAPABILITY in the Prolog language: there
is large and growing amount of software written in Common Lisp which
will NEVER execute efficiently on standalone Prolog systems. On the
other hand Prolog programs will ALREADY execute efficiently on Lisp
systems. Thus the compiler which Clocksin proposes does not address
the fundamental problems of Prolog.
------------------------------
Date: Thu, 24 Oct 85 20:32:10 PDT
From: Adolfo Di-Mare <dimare@LOCUS.UCLA.EDU>
Subject: DCG + Left Recursion :- Succeed!
After looking into the dragon book, I found the trick I needed
to do avoid left recursion but still have left associative
operators.
The problem is how to evaluate arithmetic expressions with left
associative operators. The naive way is to say:
expr(Z) --> expr(Y), "-", term(X), {Z is X-Y}.
expr(Z) --> term(Z).
term(X) --> [C], {48=<C, C=<57, X is C-48}.
If we call:
| ?- expr(Z,"2-3-5-1",[]).
this program loops.
The trick is very simple: inherit from the left (above) the
left operand, and use it right away when building the expression
tree. The modified grammar:
expr(Tree) --> term(Left), rest(Left,Tree).
rest(Left,Tree) --> "-",term(Right),{Temp is Left-Right},rest
(Temp,Tree).
rest(Tree,Tree) --> [].
term(X) --> [C], {48=<C, C=<57, X is C-48}.
The call
| ?- expr(Z,"2-3-5-1",[]).
now gives the desired result: Z = -7.
Thanks to all those that helped me.
-- Adolfo
------------------------------
End of PROLOG Digest
********************
∂11-Nov-85 0945 NILSSON@SU-SCORE.ARPA New Keys
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 09:44:26 PST
Date: Mon 11 Nov 85 09:40:01-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: New Keys
To: csd@SU-SCORE.ARPA
Message-ID: <12158431689.15.NILSSON@SU-SCORE.ARPA>
For a number of reasons we decided that it was time to "re-key"
the CSD rooms in MJH. I've been told that there are probably a
number of unauthorized "master keys" floating around. These,
obviously, present security problems and place the department
at risk in case things of value disappear.
I realize quite well that there are no technical difficulties whatsoever
preventing the reappearance of unauthorized master keys. One purpose of
this msg is to let everyone know that as of today, there are no
unauthorized master keys to the new locks--because installation of the
new locks won't be completed until tomorrow.
Another purpose of the msg is to inform people that knowingly "becoming
involved with" (using, copying, creating, possessing, etc.) an
unauthorized master key will be regarded by the department
administration as a serious breach of trust. (I take it that all of us,
perhaps grudgingly, acknowledge the necessity of a system of locks and
keys. If we are serious about that, we must also acknowledge that
unauthorized master keys work to defeat that system.) I will regard
evidence of being involved with unauthorized master keys as a matter to
be referred to the President's office as a possible violation of the
Fundamental Standard.
I hope the rekeying today and tomorrow goes smoothly and causes no
one any undue hardships. Thanks, -Nils
-------
∂11-Nov-85 1043 INGRID@SU-CSLI.ARPA Symposia on AI
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 10:42:31 PST
Date: Mon 11 Nov 85 10:36:42-PST
From: Ingrid Deiwiks <INGRID@SU-CSLI.ARPA>
Subject: Symposia on AI
To: SU-Bboards@SU-CSLI.ARPA, Folks@SU-CSLI.ARPA
ANNOUNCEMENT
Soto Symposia on Artificial Intelligence
----------------------------------------
A series of three symposia on AI will be held in the Soto Lounge,
Wilbur Hall, the first three Mondays in November, at 7 p.m. These
symposia are intended to inform Stanford students and others who are
interested about the nature of AI, its prospects, and the intellectual
and social issues to which it gives rise.
The first symposium took place on Monday, November 4. The other two
are scheduled as follows:
Monday, November 11, 7 p.m.
"Can we make computers that think and talk?"
Terry Winograd Professor of Computer Science, Stanford
Brian Smith Computer Scientist, Xerox PARC
Consulting Professor of Philosophy,
Stanford
Nils Nilsson Professor of Computer Science and
Chair of Department of Computer Science,
Stanford
Monday, November 18, 7 p.m.
"Star Wars and Computation"
John McCarthy Professor of Computer Science, Stanford
David Redell DEC Research Laboratory
and possibly others
Each symposium will begin with short talks by the speakers, followed
by plenty of time for vigorous interchanges among the speakers and
with members of the audience.
Soto is the first dormitory in the Wilbur complex that one comes to
when walking out Escondido from the Undergraduate Library.
----------------------------------------------------------------------
<--UGLI Escondido Rd.
----------------------------------------------------------------------
xxxxxxxxxxxxxx X XXX XXX X
Soto --> X Wilbur X
Stern Hall X X
xxxxxxxxxxxxxx X Hall X
X X
X XXX XXX X
-------
∂11-Nov-85 1040 NILSSON@SU-SCORE.ARPA More "Keys"
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 10:39:55 PST
Date: Mon 11 Nov 85 10:37:12-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: More "Keys"
To: csd@SU-SCORE.ARPA
Message-ID: <12158442100.15.NILSSON@SU-SCORE.ARPA>
Some people have pointed out to me that "unauthorized keys" in
the possession of one or two graduate students serves a very
useful purpose. If that's so, why don't we give out one or
two such keys only we should call them "authorized" instead.
I'll talk more with LaDonna and Betty about this. In the meantime,
the student representatives might be thinking about this idea.
-Nils
-------
∂11-Nov-85 1201 INGRID@SU-CSLI.ARPA HOUSEMATE WANTED
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 12:00:59 PST
Date: Mon 11 Nov 85 11:57:02-PST
From: Ingrid Deiwiks <INGRID@SU-CSLI.ARPA>
Subject: HOUSEMATE WANTED
To: SU-bboard@SU-CSLI.ARPA, folks@SU-CSLI.ARPA
Housemate wanted, from now until mid-June 1986. Share house with
three professional journalists. Beautiful house in a beautiful
location in Palo Alto, biking distance from Stanford. Fully furnished
room, private bath, in fully furnished home; washer/dryer, dishwasher,
fireplace, backyard. $485 per month. Call 325-6737 evenings.
-------
∂11-Nov-85 1402 @SU-CSLI.ARPA:VAL@SU-AI.ARPA Non-Monotonic Reasoning Seminar
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 14:02:17 PST
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 11 Nov 85 14:00:21-PST
Date: 11 Nov 85 1346 PST
From: Vladimir Lifschitz <VAL@SU-AI.ARPA>
Subject: Non-Monotonic Reasoning Seminar
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
SOME RESULTS ON AUTOEPISTEMIC LOGIC
Wiktor Marek
University of Kentucky
2:00 PM, WEDNESDAY, November 20
MJH 252
We discuss some properties of so-called stable theories in
autoepistemic logic (cf Moore, AIJ 25 (1985)), that is, sets of beliefs of
a fully rational agent. We show an operator constructing these theories out
of their objective parts and investigate the complexity of the construction.
We attempt to extend Moore's approach to the case of predicate logic.
Finally, we discuss the notion of inessential modal extension of a first
order theory.
∂11-Nov-85 1455 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #30
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 14:55:06 PST
Date: 11 Nov 85 1421-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #30
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Monday, 11 Nov 1985 Volume 1 : Issue 30
Today's Topics:
XLISP on a Cray is Interpreted (2 messages)
Actors and Objects
Vectorized Lisp and Multiprocessor Lisp
Seminar: BFCP and GHC - Alternatives to Concurrent Prolog (MIT)
----------------------------------------------------------------------
Date: Sun, 10 Nov 85 11:44:17 EST
From: "William J. Bogstad" <bogstad@hopkins-eecs-bravo.ARPA>
Subject: Speed improvement of a Cray
It should be noted that XLISP, the version of LISP ported to
the Cray, is strictly an interpreter. Given this fact, the order of
magnitude loss which appears to occur may not be there.
Bill Bogstad
bogstad@hopkins.arpa
------------------------------
Date: Sun, 10 Nov 85 17:13:18 EST
From: Frank Ritter <ritter@BBN-LABS-B.ARPA>
Subject: XLISP on a Cray
XLISP runs only interpreted; there is no compiler for it. You can
easily see about an order of magnitude in speed between compiled and
interpreted in other lisps. The 3600 makes it very easy to always
only run the compiled version. So that's where the X10 went: compiled
(less filling) vs. interpreted (debugs great).
Frank
------------------------------
Date: 10 Nov 85 (Sun) 13:26:02 EST
From: Jim Hendler <jah%brown.csnet@CSNET-RELAY.ARPA>
Subject: PARSYM Digest V1 #29
Recent mailings re. Smalltalk and etc. lead me to believe that the
readers of this net share a certain confusion with most of the rest of
the world. The problem is that there has been an amazing obfuscation
that has resulted from the linking of the terms "object-oriented" and
"message-passing." Flavors, Smalltalk, and LOOPS are definitely
object-oriented languages, however their control structure is still
the basic stack structure of FUNCALL. I believe that there is a clear
distinction between this and the "message passing" work that seems a
better model for parallelism. Consider the following example:
Byron asks you what time it is, you know that I have a watch
(you don't). When you ask me for the time, why should I reply
to you (causing you to be in a wait state). You'd rather send
out a message to me saying "What time is it (oh, by the way,
give the answer to Byron, not to me)?"
I haven't used actors in nearly 5 years, but I recall it had something
resembling true message-passing. Brian Phillips and I, then at Texas
Instruments, hacked up a system in Interlisp that did actual
message-passing of this type [the implementation used the spaghetti
stacks of Interlisp. It was quite slow and one could only leave a
small number of unanswered messages around before things broke.] We
found some interesting properties to the algorithms we were able to
design using the new control (this was briefly described in an old
technical report called "A flexible control structure for the
conceptual analysis of natural language using message-passing" -- the
Interlisp code for the message-passing system is in an appendix).
This research was shelved while I pursued my doctoral research. Now
that that is nearly done I will be starting some work at the
University of Maryland (as of Jan 1) to continue some present work on
object-oriented computing and to work some new ideas on
message-passing into a flavors-like object-oriented system. I'm open
for advice, comments, and etc.
-Jim Hendler
Brown U.
[best e-mail address is Hendler@tove]
------------------------------
Date: Sun, 10 Nov 85 16:24:09 cst
From: harrison@uicsrd.CSRD.UIUC.EDU (Luddy Harrison)
Subject: PARSYM Digest V1 #29
[Eugene Miya asked how Lisp could be vectorized. Byron Davies asked
whether a functional subset of Lisp would be appropriate for
vectorization. -- BD]
Some time ago, I mentioned that we are working on the
compilation of lisp for multiprocessors. In fact, I mentioned that I
would soon have a report available for the asking concerning the
details of the compilation process. Let me first apologize to those
who have waited for this paper: what started out to be a brief
overview of the compiler has become several hundred pages of detailed
description, with lots of figures and so on. I have kept a list of
all who have requested this document, and will send it out as soon as
it is complete.
Vectorization refers ordinarily to the compilation of a
program (usually in FORTRAN) for a vector machine, such as the Cray,
or perhaps an array processor. There are several reasons why
"vectorizing" lisp is difficult:
1) Vector machines perform best when executing a single operation over
many elements of a vector. Usually this is a simple operation such as
addition or multiplication; at any rate, the operation itself can
usually not be defined in software. That is, only those operations
directly supported by the hardware may be performed upon the vector
register. This means that even if we could overcome the problem of
gathering the elements of a list into a vector register, the types of
operations that we could perform upon them would not allow the
generality of say, a mapcar function. And even if we could somehow
make mapcar perform well, more complex functions (most of real lisp
programs) would not be easily pressed into such a tight mold.
2) It is well known that frequent branching degrades the performance
of a pipelined architecture. The way that this is ordinarily overcome
is by the translation of conditional expressions into mode vectors,
which serve as additional vector inputs to the pipe. For instance,
the statement
if p(x[i]) then a[i] := b[i] + c[i]
might be compiled as
dovector q[i] := p(x[i])
dovector a[i] := b[i] + c[i] where q[i].
The vector q is called a mode vector. An analagous translation is
possible in the case of lisp programs, but I don't think that anyone
(other than us) has described the way it can be done. (But as I
pointed out, unless we want to perform floating point operations on
lists, which seems rather un-lispish to me, this is not likely to get
us very far.) Without such a translation, we would be limited to very
simple operations indeed, upon the lists that we somehow got into the
vector registers. For instance, we might want to perform floating
point divide (!) on every atomic element of a list; to perform this
test would require translating the test (atom x) into a mode vector.
The good news is that none of these problems exists for a
multiprocessors like CEDAR or RP3, and we think that compiling lisp
for these architectures will be quite feasible. We are not
restricting ourselves to a functional subset; it seems to be
unnecessary.
-Luddy Harrison
Center for Supercomputer Research and Development
University of Illinois
302D Talbot Laboratory
104 South Wright Street
Urbana IL 61801-2932
(217) 333 4168
------------------------------
Date: Sun, 10 Nov 85 00:56:01 EST
From: "Steven A. Swernofsky" <SASW@MIT-MC.ARPA>
Subject: Forwarded seminar announcement
To: cog-sci-calendar
Thursday 7, November 2: 15pm Room: NE43- 7th floor playroom
BFCP and GHC - Alternatives to Concurrent Prolog
Jacob Levy
Department of Applied Mathematics
Weizmann Institute of Science
This talk will discuss some of the alternatives to Concurrent Prolog
recently proposed. Each of these languages is designed to cover a
large subset of Concurrent prolog, but to be much easier to implement.
Flat Concurrent prolog (FCP) and Guarded Horn Clauses (GHC) will be
described in detail.
FCP, which has only And-parallelism, was developed at the Weizmann
Institute as a viable subset of Concurrent Prolog. Its current
implementation, in terms of a Warren Abstract Machine, will be
described.
The GHC language, designed by K. Ueda of ICOT, Japan, has
OR-parallelism as well as And-parallelism, but instead has more
limited synchronization primitives than Concureent Prolog. The second
part of this talk will briefly describe my implementation of GHC.
After the talk, a demo of FCP and Logix, its programming environment,
will be given.
HOSTS: Professors Gerald Jay Sussman and Henryk Jan Komorowski
(Harvard)
------------------------------
End of PARSYM Digest
********************
∂11-Nov-85 1539 CAROL@SU-CSLI.ARPA Demo postponed
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 15:38:46 PST
Date: Mon 11 Nov 85 15:33:39-PST
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: Demo postponed
To: Folks@SU-CSLI.ARPA
cc: Carol@SU-CSLI.ARPA
*********************************************************************
**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DL
Nov 11
The demo of the Gloss package, originally scheduled for Tues at
4 p.m., has been postponed until after Thanksgiving. I am sorry
for any inconvenience this may cause.
On Nov. 19 Richard Burton will demo the new Sketch. Further
information forthcoming.
-Carol (321-2136, Ventura 28)
ION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION*
*********************************************************************
-------
∂11-Nov-85 1541 TAJNAI@SU-SCORE.ARPA IBM/Forum Party 11/14/85
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 15:41:09 PST
Date: Mon 11 Nov 85 15:37:37-PST
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: IBM/Forum Party 11/14/85
To: su-bboards@SU-SCORE.ARPA
cc: csd@SU-SCORE.ARPA, csl-everyone@SU-SIERRA.ARPA
Message-ID: <12158496788.36.TAJNAI@SU-SCORE.ARPA>
IBM Research
Cordially invites
the Faculty, Staff and Students of CSD and CSL
to attend a party
Thursday, November 14, 1985
4:00 to 6:00 p.m.
Faculty Club, Gold Lounge
Sponsored by the Computer Forum
p.s. Lots of good food!!
-------
∂11-Nov-85 1644 PATASHNIK@SU-SUSHI.ARPA nonAFLB talk
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 16:43:52 PST
Date: Mon 11 Nov 85 16:44:18-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: nonAFLB talk
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12158508929.10.PATASHNIK@SU-SUSHI.ARPA>
There's a talk this Wednesday that will interest some of us:
-------
Speaker : Margaret Wright
On projected Newton Barrier Methods for LP and
an equivalence to Karmarkar's projective method
Wed, Nov 13, at 4:30 in Terman 453
-------
I know nothing about this besides what's in this message.
--Oren
-------
∂11-Nov-85 2307 DAVIES@SUMEX-AIM.ARPA No meeting this week
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 23:07:33 PST
Date: Mon, 11 Nov 1985 23:09 PST
Message-ID: <DAVIES.12158579027.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: No meeting this week
cc: Davies@SUMEX-AIM.ARPA
There will be no AAP meeting this Wednesday, November 13.
If you're looking for something to do instead, the TI Satellite
Seminar on Knowledge-Based Systems will be going on all day Wednesday.
The seminar starts at 8:15 am in Law School 290.
-- Bron
∂12-Nov-85 0812 RICHARDSON@SU-SCORE.ARPA CSD Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 08:12:46 PST
Date: Tue 12 Nov 85 08:13:03-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
cc: library@SU-SCORE.ARPA, maslin@SUMEX-AIM.ARPA
Message-ID: <12158678001.13.RICHARDSON@SU-SCORE.ARPA>
The Tuesday CSD Lunch Series will continue today with Elliot Levinthal on
the topic of CIMA.
-------
∂12-Nov-85 0835 EMMA@SU-CSLI.ARPA TINLunch
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 08:34:59 PST
Date: Tue 12 Nov 85 08:33:57-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: TINLunch
To: friends@SU-CSLI.ARPA
Tel: 497-3479
For complicated reasons, Jon Barwise's TINLunch has been moved from
December to this Thursday. His abstract follows:
``Machines and the Mental''
Fred Dretske
The paper argues that current computers do not exhibit anything that
deserves to be called rational cognitive activity. Dretske even
claims that they can't add! He then goes on to discuss how one might
build something that deserves to be called a rational machine.
This short, well-written paper is Dretske's Presidential Address to
the APA. Read it can come prepared for a lively session.
-------
∂12-Nov-85 1117 BERGMAN@SU-SCORE.ARPA RA support
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 11:17:35 PST
Date: Tue 12 Nov 85 09:32:34-PST
From: Sharon Bergman <BERGMAN@SU-SCORE.ARPA>
Subject: RA support
To: faculty@SU-SCORE.ARPA
cc: bergman@SU-SCORE.ARPA
Message-ID: <12158692479.30.BERGMAN@SU-SCORE.ARPA>
If you need to make any changes in your support of research assistants
for Winter quarter (i.e. adding new students, stopping any appoint-
ments, changing account numbers, etc.), please let me know as soon as
possible so that I can send the paperwork through in a timely manner.
If you would like to see a list of the students my records show you are
currently supporting, please let me know and I'll send you the list.
Thanks. Sharon Bergman
-------
∂12-Nov-85 1118 NILSSON@SU-SCORE.ARPA Student Names
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 11:18:39 PST
Date: Tue 12 Nov 85 09:34:53-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Student Names
To: faculty@SU-SCORE.ARPA
Message-ID: <12158692900.31.NILSSON@SU-SCORE.ARPA>
After receiving some faculty and student responses on the matter
of sending out lists of names of graduating students (and seeing
no evidence of a faculty-adopted policy to the contrary), I suggest
the following policy to take effect immediately (unless there
is a great outpouring of sentiment against it):
Victoria Cheadle (for the Ph.D. students) and Jutta McCormick (for the
M.S. students) will maintain lists of names of CSD students graduating
within the next few months. They will do this by inviting students to
have their names on these lists. But no name will be included on the
lists unless students specifically ask to have them included. (Once
someone asks to have his/her name included, it will stay on the list
until that person asks to have it deleted--or until the student leaves
us.) Thus, the system will have a certain fail-safe feature. You have
to respond positively to Victoria's/Jutta's request in order to have
your name on the list.
These lists will be sent free of charge to anyone who asks for
them. I see no conflict here with what the Computer Forum
provides.
I hope it won't occur to people to ask if several different kinds
of lists could be maintained. (One for inquiring universities, one
for inquiring venture capital firms, etc.) That could become
an administrative nightmare.
-Nils
-------
∂12-Nov-85 1119 NILSSON@SU-SCORE.ARPA SOE Committees
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 11:19:51 PST
Date: Tue 12 Nov 85 09:49:33-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: SOE Committees
To: faculty@SU-SCORE.ARPA
Message-ID: <12158695569.31.NILSSON@SU-SCORE.ARPA>
The School of Engineering has a number of standing committees.
They have asked me for suggestions about CSD faculty who would
be appropriate to serve on these committees. These are
the committees and current membership:
Engineering Minority Program:
Ashley, Bates, Eisenhardt, Hillier, Kiremidjian, Bradford, Shevell,
Wiggins, Patterson, Leckie (chair).
Committee on Engineering in Biology and Medicine
Chang, Angell, Zajac, Robertson, Hesselink, Steele (chair)
School of Engr. Library Committee
Van Dyke, Mason, Cottle, Cantwell, Fondahl, Fraser-Smith, Freyberg, Gray,
Herrman, Howard (chair), Moffat, Plummer, Sullivan, Roberts
Committee on Computers
Homsy, Huggins, Hughes, Powell, Jucker, Gill, Kychakoff, Koseff,
Ferzinger (Chair)
SITN Advisory Committee
Kruger, White, Hausman, Knuth, Springer, Allen (Chair)
I don't know very much about what exactly these committees do.
If anyone would like to have his name suggested, please let
me know. -Nils
-------
∂12-Nov-85 1236 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 12:35:57 PST
Date: Tue 12 Nov 85 08:58:13-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12158686224.13.RICHARDSON@SU-SCORE.ARPA>
My apologies....that should read SIMA.
-------
∂12-Nov-85 1236 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 12:36:22 PST
Date: Tue 12 Nov 85 08:59:14-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12158686411.27.LIBRARY@SU-SCORE.ARPA>
Computer-Aided Database Design The DATAID Project. ed. by A. Albano,
V. de Antonellis and A. di Leva. QA76.9.D3C66 1985
PostScript Language Reference Manual. Adobe Systems Incorporated.
QA76.73.P67P67 1985.
Foundations of Programming. by Jacques Arsac. Translated by Fraser Duncan.
APIC Studies in Datat Processing no. 23. QA76.6.A75813 1985
Fundamentals of Computation Theory. FCT '85. Cottbus, GDR, Sept. 1985.
ed. by Lothar Budach. Lecture Notes In Computer Science 199.
QA267.I57 1985.
Advances In Cryptology. Proceedings of Cryto 84. ed. by G. R. Blakley and
David Chaum. Lecture Notes In Computer Science. QA76.9.A25C79.
Pattern Recognition Human and Mechanical. by Satosi Watanabe. Q327.W365
1985. c.2
The Shape Of Space How To Visualize Surfaces and Three-Dimensional
Manifolds. Pure and Appplied Mathematics Series. by Jeffrey Weeks.
QA612.2.W44 1985
Lancozos Algorithms for Large Symmetric Eigenvalue Computations.
Volume 1 Theory Volume 2 Programs. Progress in Scientific
Computing. by Jane K. Cullum and Ralph A. Willougby
QA193.C84 1985 V. 1 and V. 2
Estimating Eigenvalues With a posteriori/a priori Inequalitities.
Research Notes In Mathematics. QA374K95 1985.
Combinatorial Algorithms On Words. NATO ASI Series. ed by Alberto
Apostolico and Zvi Galil. QA164.N35 1984.
Logics and Models of Concurrent Systems. NATO ASI Series. ed by
Krzysztof R. Apt. QA76.5N16 1984.
Computational Mathematical Programming. NATO ASI Series. ed by Klaus
Schittkowski. QA402.5N365 1984.
Control Flow And Data Flow: Convepts Of Distributed Programming.
International Summer School Directed by F. L. Bauer, E. W. Dijkstra,
and C. A. R. Hoare. ed by Mangred Broy. NATO ASI Series.
QA76.9.D5N375 1984
Health Information Systems A Bibliography. by Donald Ziegenfuss and
James Ziegenfuss, Jr. Z6675.E4Z53 1984.
H. Llull
-------
∂12-Nov-85 1237 RICHARDSON@SU-SCORE.ARPA CSD 500 Colloquium Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 12:37:30 PST
Date: Tue 12 Nov 85 09:03:17-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD 500 Colloquium Series
To: faculty@SU-SCORE.ARPA
Message-ID: <12158687147.13.RICHARDSON@SU-SCORE.ARPA>
Would someone like to volunteer to introduce Pradeep Sindhu today at the
CSD 500 talk which he is giving today in Skilling at 4:15? Perhaps someone
who is already planning on attending?
-------
∂12-Nov-85 1239 NILSSON@SU-SCORE.ARPA Master Keys
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 12:39:47 PST
Date: Tue 12 Nov 85 09:15:01-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Master Keys
To: csd@SU-SCORE.ARPA
Message-ID: <12158689283.31.NILSSON@SU-SCORE.ARPA>
People have persuaded me that it is very important for a 24-hour-a-day
operation like the CSD in MJH not to be hampered by the 8-hour-a-day
policy of locking things up after hours. Things are greatly unhampered
by always having a few trusties around with a master key so that folks
can get into the rooms they would ordinarily be able to get into
during the day. A fine idea! My earlier msgs should be interpreted
as only suggesting that we might not necessarily want the trusties
to be those persons who are skilled at locksmithery. So, people
who want to volunteer to be trusties should send a msg to LaDonna,
eppley@score, and we'll select a few. -Nils
-------
∂12-Nov-85 1254 ACUFF@SUMEX-AIM.ARPA Explorer 1.0.2: anyone need it?
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 12:54:16 PST
Date: Tue 12 Nov 85 12:38:39-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Explorer 1.0.2: anyone need it?
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12158726352.18.ACUFF@SUMEX-AIM.ARPA>
If anyone wants to use Explorer release 1.0.2, please let me know,
and I'll try to set it up.
-- Rich
-------
∂12-Nov-85 1346 WASOW@SU-CSLI.ARPA consulting offer
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 13:46:35 PST
Date: Tue 12 Nov 85 13:37:48-PST
From: Tom Wasow <WASOW@SU-CSLI.ARPA>
Subject: consulting offer
To: Folks@SU-CSLI.ARPA
I have been contacted by a representative of a company called Qualogy,
which is looking for someone to evaluate some natural language translation
software that is being considered for product development. He seemed
to think that it would be a job of only a few hours, and indicated that
they would pay competitive consulting fees (though he didn't mention
a figure). Anyone interested in pursuing this should contact me.
Tom Wasow
-------
∂12-Nov-85 1448 ullman@su-aimvax.arpa paper received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 14:48:03 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 12 Nov 85 14:43:15 pst
Date: Tue, 12 Nov 85 14:43:15 pst
From: Jeff Ullman <ullman@diablo>
Subject: paper received
To: nail@diablo
"Equivalence and Optimization of Relational Transactions"
by Abiteboul and Vianu.
This doesn't seem to have much to do with logic and databases,
but rather it is a study of optimization for insert/delete
operations. Any interest?
∂12-Nov-85 1519 ullman@su-aimvax.arpa tomorrow's meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 15:18:13 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 12 Nov 85 15:08:34 pst
Date: Tue, 12 Nov 85 15:08:34 pst
From: Jeff Ullman <ullman@diablo>
Subject: tomorrow's meeting
To: nail@diablo
I have (a) no agenda and (b) a 10AM meeting with the dean
that is likely to run over the normal NAIL time.
Thus, I suggest that we either cancel the meeting or
agree that those of us who are free will gather at 11AM
and grump about something.
∂12-Nov-85 1522 MODICA@SU-SCORE.ARPA info for TV students
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 15:22:44 PST
Date: Tue 12 Nov 85 15:20:39-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: info for TV students
To: faculty@SU-SCORE.ARPA, instructors@SU-SCORE.ARPA
Message-ID: <12158755846.21.MODICA@SU-SCORE.ARPA>
PLEASE SEND ME THE FOLLOWING INFORMATION AS SOON AS POSSIBLE :
1)IF YOU ARE TEACHING A COURSE WINTER QUARTER, ARE THE STUDENTS GOING TO NEED
TO HAVE ACCESS TO ONE OF THE COMPUTING SYSTEMS (SUCH AS LOTS)?.....
2)..AND IF SO WILL TV STUDENTS HAVE THE OPTION OF USING A DIFFERENT COMPUTER?
IN YOU REPLY PLEASE INDICATE WHAT COURSE YOU WILL BE TEACHING. THE REASON I
NEED THIS INFORMATION IS THAT THOSE ARE VERY COMMON QUESTIONS FROM TV STUDENTS,
(ALONG WITH WHAT BOOKS ARE GOING TO BE USED, BUT I CAN GET THAT INFO FROM
KATHY BERG), AND I WOULD LIKE TO BE ABLE TO ANSWER THEM SO THAT THEY WON'T TRY
TO GET IN TOUCH WITH YOU. BECAUSE THEY CAN AND WILL CALL YOU SINCE THEY CAN
GET YOUR PHONE NUMBERS FROM CAMPUS INFORMATION.
THANK YOU.
GINA
-------
∂12-Nov-85 1522 MODICA@SU-SCORE.ARPA info for TV students
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 15:22:44 PST
Date: Tue 12 Nov 85 15:20:39-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: info for TV students
To: faculty@SU-SCORE.ARPA, instructors@SU-SCORE.ARPA
Message-ID: <12158755846.21.MODICA@SU-SCORE.ARPA>
PLEASE SEND ME THE FOLLOWING INFORMATION AS SOON AS POSSIBLE :
1)IF YOU ARE TEACHING A COURSE WINTER QUARTER, ARE THE STUDENTS GOING TO NEED
TO HAVE ACCESS TO ONE OF THE COMPUTING SYSTEMS (SUCH AS LOTS)?.....
2)..AND IF SO WILL TV STUDENTS HAVE THE OPTION OF USING A DIFFERENT COMPUTER?
IN YOU REPLY PLEASE INDICATE WHAT COURSE YOU WILL BE TEACHING. THE REASON I
NEED THIS INFORMATION IS THAT THOSE ARE VERY COMMON QUESTIONS FROM TV STUDENTS,
(ALONG WITH WHAT BOOKS ARE GOING TO BE USED, BUT I CAN GET THAT INFO FROM
KATHY BERG), AND I WOULD LIKE TO BE ABLE TO ANSWER THEM SO THAT THEY WON'T TRY
TO GET IN TOUCH WITH YOU. BECAUSE THEY CAN AND WILL CALL YOU SINCE THEY CAN
GET YOUR PHONE NUMBERS FROM CAMPUS INFORMATION.
THANK YOU.
GINA
-------
∂12-Nov-85 1519 ullman@su-aimvax.arpa another paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 15:15:23 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 12 Nov 85 15:07:10 pst
Date: Tue, 12 Nov 85 15:07:10 pst
From: Jeff Ullman <ullman@diablo>
Subject: another paper
To: nail@diablo
"Recursive Axioms in Deductive databases: various solutions"
by L. Vieille.
Doesn't seem to say much, but surveys the difference between
approaches. Besides, how many people have three consecutive
vowels in their name?
∂12-Nov-85 1747 PAPA@SU-SCORE.ARPA Re: another paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 17:47:41 PST
Received: from SU-SCORE.ARPA by su-aimvax.arpa with Sendmail; Tue, 12 Nov 85 17:40:57 pst
Date: Tue 12 Nov 85 17:41:18-PST
From: C. Papadimitriou <PAPA@SU-SCORE.ARPA>
Subject: Re: another paper
To: ullman@SU-AIMVAX.ARPA
Cc: nail@SU-AIMVAX.ARPA
In-Reply-To: Message from "Jeff Ullman <ullman@diablo>" of Tue 12 Nov 85 15:10:56-PST
Message-Id: <12158781449.27.PAPA@SU-SCORE.ARPA>
Gee, I guess not many people have three consecutive vowels in their name.
But then again, some names are long enough to make any pattern overwhelmingly
probable...
---Christos.
-------
∂12-Nov-85 1818 ullman@su-aimvax.arpa Re: another paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 12 Nov 85 18:09:29 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 12 Nov 85 18:01:18 pst
Date: Tue, 12 Nov 85 18:01:18 pst
From: Jeff Ullman <ullman@diablo>
Subject: Re: another paper
To: PAPA@SU-Score
Cc: nail@diablo
Well I meant in the MIDDLE of their name.
Sorry, Christos.
∂13-Nov-85 0612 PATASHNIK@SU-SUSHI.ARPA AFLB abstracts
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 06:12:40 PST
Date: Wed 13 Nov 85 06:12:16-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: AFLB abstracts
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12158918159.8.PATASHNIK@SU-SUSHI.ARPA>
These are the abstracts for the next two AFLBs:
*************************************
14-Nov-85 : Richard Anderson (Stanford & MSRI)
A Parallel Algorithm for Depth First Search
A new parallel algorithm for constructing a depth first search tree in
an undirected graph will be described. The algorithm is a P-RAM
algorithm and uses several probabilistic algorithms as subroutines.
The run time of the algorithm is 2↑{\sqrt{\log n}}. This makes it an
almost RNC algorithm, since the run time is less than n↑e for any e>0.
The standard sequential algorithm for depth first search can be shown
to be ``inherently sequential'', so this shows that substantial speed
up for depth first search is possible when a different approach is
taken.
***** Time and place: November 14, 12:30 pm in MJ352 (Bldg. 460) ******
21-Nov-85 : Ketan Mulmuley (MSRI)
Parallel algorithms for rank and matching
A parallel algorithm will be given to find the rank of a matrix. It
was not previously known how to solve this problem in NC. A new
parallel algorithm for matching will also be pressented. The
algorithm runs in log↑2 parallel time and uses randomness.
***** Time and place: November 21, 12:30 pm in MJ352 (Bldg. 460) ******
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352.
If you have a topic you would like to talk about in the AFLB seminar
please let me know. (Electronic mail: patashnik@su-sushi.arpa, phone:
(415) 497-1787). Contributions are wanted and welcome. Not all time
slots for this academic year have been filled.
More information about future and past AFLB meetings and topics are in
the file [SUSHI]<patashnik.aflb>aflb.bboard .
- Oren Patashnik
-------
∂13-Nov-85 1026 CAROL@SU-CSLI.ARPA Sketch demo
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 10:25:50 PST
Date: Wed 13 Nov 85 10:16:20-PST
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: Sketch demo
To: Folks@SU-CSLI.ARPA, LFG@SU-CSLI.ARPA, Bboard@SU-CSLI.ARPA
cc: Carol@SU-CSLI.ARPA
*********************************************************************
**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DL
9 Nov 85
Richard Burton of Xerox Parc will demonstrate the Sketch package, a
program which enables you to produce drawings or combinations of
graphics and text. These can either be saved as Sketch files, or
included in a TEdit file. Many people use Sketch to produce slides
for presentations.
Some of you are already familiar with Sketch, and may wish to explore
the subtleties of the program, or raise questions about problems you
have encountered. Since the documentation is quite clear and comp-
rehensive, it would be easy for those who are interested to spend a
bit of time familiarizing themselves with the basics of the program
so the demo can also be used not only as an introduction, but also as
an opportunity to learn more advanced features of Sketch, and raise
questions about bugs or special problems.
The demo will cover recent updates.
WHEN: Tues. 19 Nov.
WHERE: Trailer F
Call if you need the document, or if you have any questions.
-Carol (321-2136, Ventura 28)
ION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION*
*********************************************************************
-------
∂13-Nov-85 1040 CAROL@SU-CSLI.ARPA Sketch demo, correction
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 10:40:23 PST
Date: Wed 13 Nov 85 10:31:56-PST
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: Sketch demo, correction
To: Folks@SU-CSLI.ARPA, Bboard@SU-CSLI.ARPA
*********************************************************************
**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DL
13 Nov 85
**CORRECTION**
Richard Burton of Xerox Parc will demonstrate the Sketch package, a
program which enables you to produce drawings or combinations of
graphics and text. These can either be saved as Sketch files, or
included in a TEdit file. Many people use Sketch to produce slides
for presentations.
Some of you are already familiar with Sketch, and may wish to explore
the subtleties of the program, or raise questions about problems you
have encountered. Since the documentation is quite clear and comp-
rehensive, it would be easy for those who are interested to spend a
bit of time familiarizing themselves with the basics of the program
so the demo can also be used not only as an introduction, but also as
an opportunity to learn more advanced features of Sketch, and raise
questions about bugs or special problems.
The demo will cover recent updates.
WHEN: 4 p.m.
Tues. 19 Nov.
WHERE: Trailer F
Call if you need the document, or if you have any questions.
-Carol (321-2136, Ventura 28)
ION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEW**DLION**NEWS**DLION**
*********************************************************************
-------
∂13-Nov-85 1141 NILSSON@SU-SCORE.ARPA Herb Grosch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 11:41:52 PST
Date: Wed 13 Nov 85 11:41:34-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Herb Grosch
To: senior-faculty@SU-SCORE.ARPA
Message-ID: <12158978105.13.NILSSON@SU-SCORE.ARPA>
Herb Grosch has written to President Kennedy volunteering to come
to Stanford to be a "living monument." Should I be interested in
this? -Nils
-------
∂13-Nov-85 1147 DALRYMPLE@SU-CSLI.ARPA party
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 11:47:29 PST
Date: Wed 13 Nov 85 11:38:42-PST
From: Mary Dalrymple <DALRYMPLE@SU-CSLI.ARPA>
Subject: party
To: folks@SU-CSLI.ARPA, linguists@SU-CSLI.ARPA
Don't miss the second weekly Linguistics happy hour, this
Friday at 4:45 in the Greenberg Room, Linguistics Department!
-------
∂13-Nov-85 1353 ACUFF@SUMEX-AIM.ARPA Bug reports for Explorers
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 13:53:04 PST
Date: Wed 13 Nov 85 13:51:11-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Bug reports for Explorers
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12159001702.21.ACUFF@SUMEX-AIM.ARPA>
Folks,
Since we are running pre-release software on our Explorers, please
send all of your bug reports to me. In particular, please don't sent
them to the BUG-TI-EXPLORER mailing list unless you are certain that
the problem also occurs under released software. This way I can report
the problems to TI so that they can be fixed before the released
version comes out, but without misrepresenting TI's software quality
control to people who don't know that we are using pre-release software.
Thanks,
-- Rich
-------
∂13-Nov-85 1403 REGES@SU-SCORE.ARPA TAs
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 14:03:39 PST
Date: Wed 13 Nov 85 14:02:23-PST
From: Stuart Reges <REGES@SU-SCORE.ARPA>
Subject: TAs
To: faculty@SU-SCORE.ARPA
Office: Margaret Jacks 210, 497-9798
Message-ID: <12159003742.53.REGES@SU-SCORE.ARPA>
I will be appointing Winter quarter TAs very soon now. I would like to do
things a bit differently this time and appoint some people for Spring at the
same time. My basic deal will be that if they are currently a TA and are
performing satisfactorily, they will be allowed to sign up for both Winter and
Spring. Therefore, I need to know if there are any TAs who are not performing
satisfactorily. Generally our TAs do a very fine job, so I will assume that is
true unless I hear otherwise. I have already had mail from one instructor about
a TA, but I would appreciate hearing from more of you if there are more
problems.
-------
∂13-Nov-85 1606 NILSSON@SU-SCORE.ARPA Fac. Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 16:06:00 PST
Date: Wed 13 Nov 85 15:43:01-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Fac. Lunch
To: faculty@SU-SCORE.ARPA
Message-ID: <12159022059.13.NILSSON@SU-SCORE.ARPA>
I will not be able to organize a faculty lunch next Tuesday, Nov. 19
because of another commitment. If anyone would like to suggest and
lead a discussion topic in my absence please contact Anne Richardson
(Richardson@score) before tomorrow late pm so she can maintain the
usual lunch order with The New Leaf. (Otherwise, we'll just cancel
the order for next week.) -Nils
-------
∂13-Nov-85 1704 @SU-SUSHI.ARPA:broder@decwrl.DEC.COM BATS program
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 17:03:58 PST
Received: from decwrl.DEC.COM by SU-SUSHI.ARPA with TCP; Wed 13 Nov 85 17:02:01-PST
Received: from magic.ARPA (magic) by decwrl.DEC.COM (4.22.01/4.7.34)
id AA03278; Wed, 13 Nov 85 17:00:36 pst
Received: by magic.ARPA (4.22.01/4.7.34)
id AA21044; Wed, 13 Nov 85 16:58:54 pst
From: broder@decwrl.DEC.COM (Andrei Broder)
Message-Id: <8511140058.AA21044@magic.ARPA>
Date: 13 Nov 1985 1658-PST (Wednesday)
To: aflb.all@sushi.ARPA
Cc: src@decwrl.DEC.COM, allen%ucsc.CSNET@CSNET-RELAY.ARPA
Fcc: sent
Subject: BATS program
The next Bay Area Theory Seminar will be held at DEC-SRC, Friday,
November 22, starting at 10 a.m. Below is the program. Abstracts and
driving directions will be mailed separately.
Coordinators: please let me know how many people are coming from your
site in order to enable us to order an appropriate amount of food.
Uncoordinated individuals: please let me know that you are coming. (My
phone is (415) 853-2118.)
- Andrei
10:00 Lyle Ramshaw (DEC - SRC) - Beziers and B-Splines as multiaffine maps
11:00 Anna Karlin (Stanford) - An optimal algorithm for PRAM simulation using
universal hashing
12:00 Lunch
1:00 Open problems - subject to stock on hand and prior solving.
1:30 Ketan Mulmuley (U. C. Berkeley) - Parallel algorithms for rank and
matching.
2:30 Maria Klawe (IBM - Almaden) - Algorithms for embedding graphs in
multi-layer grids
∂13-Nov-85 1749 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #31
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 17:49:44 PST
Date: 13 Nov 85 1737-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #31
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 13 Nov 1985 Volume 1 : Issue 31
Today's Topics:
Lisp Vectorizable?
Smalltalk vs Actors
----------------------------------------------------------------------
Date: Tue, 12 Nov 85 13:47:55 est
From: eldridge@EDN-VAX.ARPA (Charles Eldridge)
In Re:
[Lisp on a Cray is 5-10x a Symbolics 3600, as I remember, while
Fortran on a Cray is 50-100x a VAX 780 on benchmarks of interest to
number hackers. Since a 3600 and a VAX are approximately the same
"power", give or take a factor of 2, we're missing an order of
magnitude somewhere. Is the order of magnitude due to Cray hardware
being inappropriate for Lisp or to the lack of a good Lisp compiler
for the Cray, or some combination? Would a functional subset of Lisp
be appropriate for vectorization? -- BD]
The speed of LISP is an interesting issue. I would
conjecture that these odd relationships are a consequence
of the irregularity of instructions and memory references
in the execution of LISP applications. In contrast,
vectorized problems are very regularized. It may also be
that vectorizing LISP applications would be contrary to the
high flexibility offered by that language. Vectorizing
numerical applications requires careful hand tailoring of
code in most cases. Where might LISP be hand tailored to
support vectorization? We must look for repeated application
of the same function, for example as in MAPCAR or in a recursive
function. But, in the case of MAPCAR and its relatives, we
may have a complex function to evaluate with each application.
Vectorization thrives on simpler functions that can be implemented
in hardware. In the case of recursion, the flow of control
is unpredictable. We can't see in advance where the recursion
will stop.
LISP processing has been optimized at the microscopic or local
level using specialized instruction set architectures to
manipulate list structures. A more global analysis, as would
be obtained by running LISP applications in a simulated mode
in order to view instruction and memory reference patterns, will be
necessary to ascertain whether a subset of LISP is appropriate
for vectorizing.
--Charles Eldridge
------------------------------
Date: 12 Nov 1985 20:34:26-EST
From: linus!brando@mitre-bedford.ARPA
Date: Tue, 12 Nov 85 15:31:10 est
From: T. J. Brando <linus!brando>
Subject: Smalltalk vs Actors
The remarks that have been made by schwamb@mitre.ARPA and Hendler@tove
describing the *key* or *clear distinctions* between object-oriented
paradigms and message-passing paradigms have only served to strengthen
my belief that there is no essential difference between Actors and the
other object-oriented paradigms that have been mentioned. A careful
reading of the postings of Karl and Jim points out that they are, in
fact, comparing object-oriented *paradigms* with message-passing
*implementations*. *Of course* the object-oriented implementations to
date have been sequential, because they were done on sequential machines!
On the other hand, Actors is being *designed* to execute in a multiple
processor environment! How do the two *paradigms* compare, however, if
we *implement* message passing in a Smalltalk system such that each
message contains the identity of the object to which the response should
be sent (or nil, if no response is needed), and a sending object can
wait for a response or continue executing immediately after sending a
message?
Thom
linus!brando@mitre-bedford.arpa
------------------------------
End of PARSYM Digest
********************
∂13-Nov-85 1758 EMMA@SU-CSLI.ARPA Newsletter November 14, No. 2
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 17:57:58 PST
Date: Wed 13 Nov 85 17:05:26-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter November 14, No. 2
To: friends@SU-CSLI.ARPA
Tel: 497-3479
!
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
November 14, 1985 Stanford Vol. 3, No. 2
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, November 14, 1985
12 noon TINLunch
Ventura Hall Machines and the Mental
Conference Room by Fred Dretske
Discussion led by Jon Barwise (Barwise@su-csli.arpa)
(Abstract on page 2)
2:15 p.m. CSLI Seminar
Redwood Hall A Morphological Recognizer with Syntactic and
Room G-19 Phonological Rules
John Bear (Bear@sri-ai.arpa)
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Redwood Hall Partial Truth Conditions and Their Logics
Room G-19 Hans Kamp, University of Texas
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *NEXT* THURSDAY, November 21, 1985
12 noon TINLunch
Ventura Hall Parsing as Deduction?
Conference Room by Fernando Pereira and David Warren
Discussion led by Mark Johnson (Johnson@su-csli.arpa)
(Abstract will appear next week)
2:15 p.m. CSLI Seminar
Redwood Hall Interactive Modularity
Room G-19 Ron Kaplan, Xerox PARC (Kaplan.pa@xerox.arpa)
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Redwood Hall An Introduction to Information-based Complexity
Room G-19 J. F. Traub, Computer Science Department, Columbia
(Abstract on page 3)
←←←←←←←←←←←←
!
Page 2 CSLI Newsletter November 14, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
THIS WEEK'S TINLUNCH
Machines and the Mental
by Fred Dretske
The paper argues that current computers do not exhibit anything
that deserves to be called rational cognitive activity. Dretske even
claims that they can't add! He then goes on to discuss how one might
build something that deserves to be called a rational machine.
This short, well-written paper is Dretske's Presidential Address to
the APA. Read it and come prepared for a lively session. --Jon Barwise
←←←←←←←←←←←←
THIS WEEK'S CSLI SEMINAR
A Morphological Recognizer
with Syntactic and Phonological Rules
In many natural language processing systems currently in use the
morphological phenomena are handled by programs which do not interpret
any sort of rules, but rather contain references to particular
morphemes, graphemes, and grammatical categories. Recently
Koskenniemi, Karttunen, Kaplan and Kay have showed how to build
morphological analyzers in which the descriptions of the phonological
(or orthographic) and syntactic phenomena are separable from the code.
A system will be described which is based on the work of the people
mentioned above. There are two main differences between the system to
be described here and other existing systems of its kind. Firstly,
the spelling rules are not translated into finite state transducers,
but are interpreted directly, thereby yielding a system more amenable
to grammar development than one in which considerable time is
necessary to compile the rules into transducers. Secondly, the
syntactic component has more flexibility than other current systems.
Instead of encoding the syntax entirely in the lexicon by stipulating
about each morpheme what category it is and what category may come
next, this system contains a file of patr-type rules with the power to
unify dags containing disjunctions. --John Bear
----------
NEXT WEEK'S SEMINAR
Interactive Modularity
Ron Kaplan, Xerox PARC
Comprehensible scientific explanations for most complex natural
phenomena are modular in character. Phenomena are explained in terms
of the operation of separate and independent components, with
relatively minor interactions. Modular accounts of complex cognitive
phenomena, such as language processing, have also been proposed, with
distinctions between phonological, syntactic, semantic, and pragmatic
modules, for example, and with distinctions among various rules within
modules. But these modular accounts seem incompatible with the
commonplace observations of substantial interactions across component
boundaries: semantic and pragmatic factors, for instance, can be shown
to operate even before the first couple of phonemes in an utterance
have been identified. In this talk I consider several methods of
reconciling modular descriptions in service of scientific explanation
with the apparent interactivity of on-line behavior. Run-time methods
utilize interpreters that allow on-line interleaving of operations
from different modules, perhaps including additional ``scheduling''
!
Page 3 CSLI Newsletter November 14, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
components for controlling the cross-module flow of information. But
depending on their mathematical properties, modular specifications may
also be transformed by off-line, compile-time operations into new
specifications that directly represent all possible cross-module
interactions. Such compilation techniques allow for run-time
elimination of module boundaries and of intermediate levels of
representation.
----------
NEXT WEEK'S COLLOQUIUM
An Introduction to Information-based Complexity
J. F. Traub
Computer Science Department, Columbia University
In information-based complexity ``information'' is, informally,
what we know about a problem which we wish to solve.
The goal of information-based complexity is to create a general
theory about problems with partial and contaminated information and to
apply the results to solving specific problems in varied disciplines.
Problems with partial and contaminated information occur in areas such
as vision, medical imaging, prediction, geophysical exploration,
signal processing, control, and scientific and engineering
calculation.
For problems with partial and contaminated information, very general
results can be obtained at the ``information level.'' Among the
general results to be discussed is the power of parallel
(non-adaptive) information and the application of such information to
the solution of problems on distributed systems.
The methodology and results of information-based complexity will be
contrasted with the study of NP-complete problems where the
information is assumed to be complete, exact, and free.
----------
PIXELS AND PREDICATES
Setting Tables and Illustrations with Style
Rick Beach, Xerox PARC, (Beach.pa@xerox.arpa)
CSLI trailers, 1:00 p.m., Wednesday, November 20, 1985
Two difficult examples of incorporating complex information within
electronic documents are illustrations and tables. The notion of
style, a way of maintaining consistency, helps manage the complexities
of formatting both tables and illustrations. The concept of graphical
style extends document style to illustrations. Observing that
graphical style does not adequately deal with the layout of
information leads to the study of formatting tabular material. A grid
system for describing the arrangement of information in a table, and a
constraint solver for determining the layout of the table are key
components of this research. These ideas appear to extend to
formatting other complex material, including mathematical typesetting
and page layout. Several typographic issues for illustrations and
tables will be highlighted during the talk.
!
Page 4 CSLI Newsletter November 14, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
LEXICAL PROJECT MEETING
Lori Levin, University of Pittsburgh
Monday, November 18, 10 a.m., Ventura Conference Room
I will describe a theory of relation changing rules which is
compatible with LFG. The theory accounts for the interaction between
semantically conditioned and syntactically productive relation
changing rules, ability of relation changing rules to distinguish
between subjects of unaccusative verbs and subjects of unergative
verbs, and the apparent directionality of object-to-subject relation
changes. In order to handle these properties of relation changing
rules, I introduce a new mechanism which I call Argument
Classification which mediates between thematic roles and grammatical
functions in the lexicon. I will illustrate the formulation of
various relation changing rules in English and Dutch using argument
classification.
(This talk is part of the Lexical Project meetings but open to
everybody.)
----------
ENVIRONMENTS GROUP MEETING
An Environment for VLSI Design
Mike Spreitzer, Xerox PARC, (Spreitzer@xerox.arpa)
Monday, November 18, noon, Ventura Seminar Room
We in the PARC CSL VLSI CAD group are working on making our tools
more integrated than they have been. We are defining an in-memory
data structure for representing the basic structure of a VLSI design.
Other information is hung on this "skeleton" via property lists.
Various tools communicate with each other through this decorated
structure. We think this will make it easier for the tools to
cooperate more closely than in the past.
----------
COMMON SENSE AND NON-MONOTONIC REASONING SEMINAR
Some Results on Autoepistemic Logic
Wiktor Marek, University of Kentucky
2:00 PM, Wednesday, November 20, MJH 252
We discuss some properties of so-called stable theories in
autoepistemic logic (cf. Moore, AIJ 25 (1985)), that is, sets of
beliefs of a fully rational agent. We show an operator constructing
these theories out of their objective parts and investigate the
complexity of the construction. We attempt to extend Moore's approach
to the case of predicate logic. Finally, we discuss the notion of
inessential modal extension of a first order theory.
----------
NEW CSLI REPORT
Report No. CSLI-85-36, ``Limits of Correctness in Computers'' by
Brian Cantwell Smith, has just been published. This report may be
obtained by writing to David Brown, CSLI, Ventura Hall, Stanford, CA
94305 or Brown@SU-CSLI.
-------
∂13-Nov-85 1809 @SU-SUSHI.ARPA:broder@decwrl.DEC.COM Driving to Bats
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 18:09:50 PST
Received: from decwrl.DEC.COM by SU-SUSHI.ARPA with TCP; Wed 13 Nov 85 18:05:46-PST
Received: from magic.ARPA (magic) by decwrl.DEC.COM (4.22.01/4.7.34)
id AA03893; Wed, 13 Nov 85 18:05:01 pst
Received: by magic.ARPA (4.22.01/4.7.34)
id AA23937; Wed, 13 Nov 85 18:04:27 pst
From: broder@decwrl.DEC.COM (Andrei Broder)
Message-Id: <8511140204.AA23937@magic.ARPA>
Date: 13 Nov 1985 1804-PST (Wednesday)
To: aflb.all@sushi.ARPA
Cc:
Fcc: sent
Subject: Driving to Bats
Where is DEC located?
DEC-SRC is located at 130 Lytton Ave., in Palo Alto. That is the red
brick building on the corner of Lytton and Alma, opposite Bagel Works.
Lytton is parallel to University and is the next street north. Alma is
parallel to El Camino and is the next street east (towards 101).
University is the street that continues Palm Drive. The other end of
Palm Drive is the oval in front of Stanford CSD. The total distance
from CSD to DEC is about 1 mile.
Public transportation:
DEC is one minute away from the Southern Pacific train station and the Palo
Alto bus depot.
Driving:
The entrance into our parking structure is from High street. High is
parallel is one block east of Alma and is a one-way street going from
Lytton towards University. Hence you need to get first on Lytton, turn
on High, and then immediately turn right into the parking structure.
For out-of-towners: Exit 101 at University towards Palo Alto.
Continue on University until Middlefield (the first larger
intersection). Turn right on Middlefield and after just one block turn
left on Lytton. Continue on Lytton till High (the penultimate stop
light on Lytton - Lytton ends in Alma) Turn left on High and
immediately right into the parking.
IN THE PARKING: By the time you arrive probably all ground level
parking will be full. On the left side, at the end, there is a ramp
that takes you to more parking spaces on the roof. Register your car
at the front desk.
Biking: There is some parking area for bikes near the front entrance.
It is generally closed, so that you might have to ask the person at the
front desk to open it for you.
See you next Friday! - Andrei
∂13-Nov-85 1829 @SU-SCORE.ARPA:coraki!pratt@su-navajo.arpa Herb Grosch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 18:29:35 PST
Received: from su-navajo.arpa by SU-SCORE.ARPA with TCP; Wed 13 Nov 85 18:10:41-PST
Received: by su-navajo.arpa with Sendmail; Wed, 13 Nov 85 18:10:35 pst
Received: by coraki.uucp (1.1/SMI-1.2)
id AA25633; Wed, 13 Nov 85 13:07:05 pst
Date: Wed, 13 Nov 85 13:07:05 pst
From: coraki!pratt@su-navajo.arpa (Vaughan Pratt)
Message-Id: <8511132107.AA25633@coraki.uucp>
To: senior-faculty@su-score.ARPA
Subject: Herb Grosch
Did Herb say where he'd like to be erected? The front of the Reagan library
springs to mind.
On many occasions, most visibly during his tenure as ACM president, Herb
played the role of the shrill anti-intellectual. I found it hard to
identify with ACM's objectives during this time. A vote for Herb is
my mind a vote counter to what academia in general and this department
in particular stands for - the unfettered pursuit of knowledge.
-v
∂13-Nov-85 2319 @SU-SCORE.ARPA:coraki!pratt@su-navajo.arpa Fac. Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Nov 85 23:19:24 PST
Received: from su-navajo.arpa by SU-SCORE.ARPA with TCP; Wed 13 Nov 85 23:18:55-PST
Received: by su-navajo.arpa with Sendmail; Wed, 13 Nov 85 23:18:50 pst
Received: by coraki.uucp (1.1/SMI-1.2)
id AA26168; Wed, 13 Nov 85 23:12:53 pst
Date: Wed, 13 Nov 85 23:12:53 pst
From: coraki!pratt@su-navajo.arpa (Vaughan Pratt)
Message-Id: <8511140712.AA26168@coraki.uucp>
To: faculty@su-score.ARPA, richardson@su-score.ARPA
Subject: Fac. Lunch
I will be happy to lead a discussion on either Dolce Far Niente, or on
what happened at the EE retreat, as people prefer. (The former topic
was intended to be discussed frequently at these lunches when I first
proposed to Gene that we have them. Not having a pressing topic for
discussion was not meant to be a reason for the faculty not to be
sociable.)
-v
∂14-Nov-85 0002 Operator@SU-SUSHI.ARPA bats at dec, 11/22
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 00:02:29 PST
Date: Thursday, 14-Nov-85 00:00:36-PST
From: JF@SU-SUSHI.ARPA
Sender: The Remind Daemon <Operator>
Subject: bats at dec, 11/22
To: aflb.su
Please let me know whether you would like to attend bats at decsrc on
friday, nov. 22. the talk titles are in
SUSHI:<JF>bats.announce
I will send you a copy of the file if you don't have a sushi account
-Joan Feigenbaum
(jf@sushi)
-------
∂14-Nov-85 0830 EMMA@SU-CSLI.ARPA Newsletter addition
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 08:30:05 PST
Date: Thu 14 Nov 85 08:25:39-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter addition
To: friends@SU-CSLI.ARPA
cc: newsletter@SU-CSLI.ARPA
Tel: 497-3479
The following was omitted from the newsletter.
LOGIC SEMINAR
Truth, the Liar, and Circular Propositions, Cont.
Jon Barwise and John Etchemendy
Friday, November 15, 1985
Last time John Etchemendy gave an informal introduction to Peter
Aczel's set theory ZF/AFA, and showed how to use it to model the
Austinian conception of proposition. He then discussed how the Liar,
the truth-teller, and other paradoxes and puzzles come out in this
model. This week I will review ZF/AFA very briefly and then use it to
model the Russellian conception of proposition, and discuss how the
same puzzles come out in this model. --Jon Barwise
Noon, Math Faculty Lounge, building 380.
-------
-------
∂14-Nov-85 1109 @SU-SCORE.ARPA:guibas@decwrl.DEC.COM Re: info for TV students
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 11:06:42 PST
Received: from decwrl.DEC.COM by SU-SCORE.ARPA with TCP; Thu 14 Nov 85 10:06:51-PST
Received: from magic.ARPA (magic) by decwrl.DEC.COM (4.22.01/4.7.34)
id AA15192; Thu, 14 Nov 85 10:06:27 pst
Received: by magic.ARPA (4.22.01/4.7.34)
id AA03480; Thu, 14 Nov 85 10:05:52 pst
From: guibas@decwrl.DEC.COM (Leo Guibas)
Message-Id: <8511141805.AA03480@magic.ARPA>
Date: 14 Nov 1985 1005-PST (Thursday)
To: Gina Modica <MODICA@SU-SCORE.ARPA>
Cc: faculty@SU-SCORE.ARPA, instructors@SU-SCORE.ARPA
Subject: Re: info for TV students
In-Reply-To: Your message of Tue 12 Nov 85 15:20:39-PST.
<12158755846.21.MODICA@SU-SCORE.ARPA>
1) CS248: the students will need to use a 512k Macintosh (there are two
clusters of such machines in Terman).
2) no, but many may have access to 512k Macs on their own.
L.
∂14-Nov-85 1109 @SU-SCORE.ARPA:guibas@decwrl.DEC.COM Re: info for TV students
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 11:06:42 PST
Received: from decwrl.DEC.COM by SU-SCORE.ARPA with TCP; Thu 14 Nov 85 10:06:51-PST
Received: from magic.ARPA (magic) by decwrl.DEC.COM (4.22.01/4.7.34)
id AA15192; Thu, 14 Nov 85 10:06:27 pst
Received: by magic.ARPA (4.22.01/4.7.34)
id AA03480; Thu, 14 Nov 85 10:05:52 pst
From: guibas@decwrl.DEC.COM (Leo Guibas)
Message-Id: <8511141805.AA03480@magic.ARPA>
Date: 14 Nov 1985 1005-PST (Thursday)
To: Gina Modica <MODICA@SU-SCORE.ARPA>
Cc: faculty@SU-SCORE.ARPA, instructors@SU-SCORE.ARPA
Subject: Re: info for TV students
In-Reply-To: Your message of Tue 12 Nov 85 15:20:39-PST.
<12158755846.21.MODICA@SU-SCORE.ARPA>
1) CS248: the students will need to use a 512k Macintosh (there are two
clusters of such machines in Terman).
2) no, but many may have access to 512k Macs on their own.
L.
∂14-Nov-85 1343 CAROL@SU-CSLI.ARPA Meet the Author
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 13:43:08 PST
Date: Thu 14 Nov 85 13:34:10-PST
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: Meet the Author
To: Folks@SU-CSLI.ARPA, Bboard@SU-CSLI.ARPA
cc: Carol@SU-CSLI.ARPA
*********************************************************************
**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DL
14 Nov 85
**MEET THE AUTHOR**
Richard Burton of Xerox Parc will demonstrate SKETCH, and entertain
questions (and you).
WHEN: 4 p.m.
Tues. 19 Nov.
WHERE: Trailer F
Contact me if you need the document, a quick introductory lesson,
or if you have any questions. There is a brief version of the
documentation on {CSLI}<DANDELION.DOC>SKETCH, and in the
yellow binders.
-Carol (321-2136, Ventura 28)
ION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION*
*********************************************************************
-------
∂14-Nov-85 1405 BSCOTT@SU-SCORE.ARPA Proposals
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 14:05:43 PST
Date: Thu 14 Nov 85 14:04:20-PST
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: Proposals
To: Academic-Council@SU-SCORE.ARPA
cc: Donoghue@SU-SCORE.ARPA, Mathy@SU-SCORE.ARPA, Anderson@SU-NAVAJO.ARPA
Message-ID: <12159266239.39.BSCOTT@SU-SCORE.ARPA>
It has come to my attention that because of a rush deadline to be met a
proposal was sent to the agency this week without appropriate signatures.
I think that most of you know that is an absolute no-no. And, the agency
has called and said that signed copies must be submitted, so all the work
has to be duplicated. Plus, though I don't know this first hand, I understand
that the proposal which was sent contained errors which had to be corrected.
Anyway, this note is to remind you all of the University/SPO requirements.
I also want to remind you that we do need a little turnaround time to pro-
cess proposals, and that it is extremely inconsiderate to ask that budgets
be prepared, proposals checked, etc., on a overnight basis. Mary Donoghue
and other staff concerned with proposals simply cannot provide this kind of
service. In the future, I will much appreciate your exerting every effort
to give advance notice of a proposal submission and then to allow a reasonable
time period in which to have it prepared, processed through SPO and mailed.
Thanks in advance.
Betty
-------
∂14-Nov-85 1434 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH plus other business...
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 14:33:40 PST
Date: Thu 14 Nov 85 14:31:42-PST
From: LANSKY@SRI-AI.ARPA
Subject: Next Monday's PLANLUNCH plus other business...
To: planlunch.dis: ;
PLANLUNCHers:
I have recently received a request not to send out PLANLUNCH reminders
(i.e. the message I send out the day previous to the talk). My only fear is
that this reminder message is the main reason PLANLUNCH has had such good
attendance! I am, however, willing to form two mailing lists --
planlunch + planlunch-reminder.
If you DO NOT wish to be on the reminder list, please send me a message.
(Unfortunately, though, if you happen to be on MUGS or JMC-LISTS I will have
a hard time deleting you unless someone sends me the contents of those
lists...).
Also note that I will henceforth try to include the computer net
address of the speaker in planlunch announcements.
-Amy Lansky
-------------------------------------------------------------------------
EXPLOITATION OF CONSTRAINTS IN DEDUCTIVE DESIGN SYNTHESIS
Jeff Finger
Stanford University
11:00 AM, MONDAY, November 18
SRI International, Building E, Room EJ228 (new conference room)
The talk will cover two related topics in deductive design synthesis:
(1) efficiency gained by reasoning forward from subgoals, and
(2) advantages and disadvantages of using a declarative representation
for partially completed designs.
The first part of the talk gives the deductive framework for capturing the
following intuition:
Suppose I have decided that X and Y and to be true of my
design. Perhaps I should think about what else X and Y imply
about the design, say Z. Otherwise, I might waste time
trying to complete the design process by making decisions
that have *already* been ruled out by X and Y, for example,
NOT(Z).
The conditions that X and Y imply (called "necessary constraints" or "NC's")
are found via reasoning forward from subgoals. We show how NC's of a
subgoal can be used to prune the design space either by preventing some
impossible possibilities from ever being generated or by providing a quick
means of filtering bad choices. In terms of resolution, the above use of
NC's corresponds to the rather counterintuitive notion of allowing
OR-INTRODUCTION on clauses in the set of support. We will also discuss
inheritance of NC's from goal to subgoal and the relation of finding NC's to
that of checking consistency of partially completed designs.
The second part of the talk deals with declarative representation of
partially completed designs. Deductive design systems such as QA3 or Manna
and Waldinger's reify the design as a single term in the logic.
However, it is difficult to express many sorts of constraints on partially
completed designs as a single term. Examples include two actions in an
unspecified order, or the constraint that Action A takes place less than 3
seconds or more than 8 seconds after Action B. We present a system called
RESIDUE in which we build up the design as a set of facts we are willing to
assume about of the design. Using facts rather than a single term, we can
make finer-grained decisions, avoiding unwitting commitments that might
result in unnecessary backtracking. In addition, forward reasoning on
subgoals (as in the first portion of the talk) may be done directly on the
set of facts.
-------
-------
∂14-Nov-85 1459 PHILOSOPHY@SU-CSLI.ARPA Colloquium
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 14:59:11 PST
Date: Thu 14 Nov 85 14:44:41-PST
From: Eve Wasmer <PHILOSOPHY@SU-CSLI.ARPA>
Subject: Colloquium
To: bboard@SU-CSLI.ARPA
cc: folks@SU-CSLI.ARPA
PHILOSOPHY DEPARTMENT COLLOQUIUM
David Hilbert
Stanford
COLORS AND SCIENCE
Friday, November 22 3:15 p.m.
Philosophy Seminar Room 92Q
-------
∂14-Nov-85 1515 LANSKY@SRI-AI.ARPA oops!
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 15:12:35 PST
Date: Thu 14 Nov 85 14:37:03-PST
From: LANSKY@SRI-AI.ARPA
Subject: oops!
To: planlunch.dis: ;
I guess my temporal logic was wrong -- ``henceforth'' does include NOW!
Jeff Finger's net address is: JFINGER@SUSHI.
-Amy
-------
∂14-Nov-85 2006 admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 19 (R. Alterman, UCB)
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 14 Nov 85 20:06:46 PST
Received: by ucbvax.berkeley.edu (5.31/1.2)
id AA04624; Thu, 14 Nov 85 16:55:28 PST
Received: by cogsci (5.31/5.13)
id AA05204; Thu, 14 Nov 85 16:57:53 PST
Date: Thu, 14 Nov 85 16:57:53 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8511150057.AA05204@cogsci>
To: cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Nov. 19 (R. Alterman, UCB)
BERKELEY COGNITIVE SCIENCE PROGRAM
$9 ←λF←λa←λl←λl ←λ1←λ9←λ8←λ5
$9 Cognitive Science Seminar - IDS 237A
$9 Tuesday, November 19, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``Adaptive Planning is Commonsense Planning''
Richard Alterman
Computer Science Division, U.C.B.
A characteristic of commonsense planning is that it is
knowledge intensive. For most mundane sorts of situations
human planners have access to, and are capable of exploiting,
large quantities of knowledge. Commonsense planners re-use old
plans under their normal circumstances. Moreover, commonsense
planners are capable of refitting old plans to novel cir-
cumstances. A commonsense planner can plan about a wide range
of phenomena, not so much because his/her depth of knowledge is
consistent throughout that range, but because s/he can re-fit
old plans to novel contexts.
This talk is about an approach to commonsense planning
called ←λa←λd←λa←λp←λt←λi←λv←λe ←λp←λl←λa←λn←λn←λi←λn←λg. An adaptive planner plans by exploit-
ing planning knowledge in a manner that delays the reduction of
commonsense planning to problem-solving. Key elements in the
theory of adaptive planning are its treatment of background
knowledge and the introduction of a notion of planning by
situation matching. This talk will describe adaptive planning
as it applies to a number of commonsense planning situations,
including: riding the NYC subway, trading books, transferring
planes at JFK airport, and driving a rented car.
----------------------------------------------------------------
UPCOMING TALKS
$9 November 26:Eve Clark, Linguistics, Stanford
December 3:Bernard Baars, Langley Porter, UCSF
----------------------------------------------------------------
ELSEWHERE ON CAMPUS
Jeff Shrager of Xerox PARC will speak on ``Instructionless
Learning'' at the SESAME Colloquium on November 18, 2515 Tolman
Hall, 4:00pm.
The Physics Department is sponsoring a talk by J. J. Hopfield
of CALTECH on Wednesday, November 20 at 4:30pm in 1 Le Conte.
Dr. Hopfield will be speaking on ``Neural Networks.'' A tea
precedes the talk.
∂14-Nov-85 2017 SF@SU-CSLI.ARPA Talk by Rachel Feferman
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 20:17:30 PST
Date: Thu 14 Nov 85 15:17:47-PST
From: Sol Feferman <SF@SU-CSLI.ARPA>
Subject: Talk by Rachel Feferman
To: bboard@SU-CSLI.ARPA, folks@SU-CSLI.ARPA
Saturday Nov. 16 and Sunday Nov. 17 at 8:00
EYES HEART HAND: A translation in images
Rachel Feferman
A slide show/talk about her work and the creative process
Animated films, drawings, paintings, doll-figures
at
Watercourse Way Movement Center 855 High Street at Channing
doors open at 7:30
Seating limited Tickets $5.00 to reserve call:493-4540
ART WORK WILL BE ON DISPLAY AND FOR SALE
SUNDAY RECEPTION 2-5pm
-------
∂14-Nov-85 2023 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 19 (R. Alterman, UCB)
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 20:23:20 PST
Received: from ucbvax.berkeley.edu by SU-CSLI.ARPA with TCP; Thu 14 Nov 85 19:58:52-PST
Received: by ucbvax.berkeley.edu (5.31/1.2)
id AA04624; Thu, 14 Nov 85 16:55:28 PST
Received: by cogsci (5.31/5.13)
id AA05204; Thu, 14 Nov 85 16:57:53 PST
Date: Thu, 14 Nov 85 16:57:53 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8511150057.AA05204@cogsci>
To: cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Nov. 19 (R. Alterman, UCB)
BERKELEY COGNITIVE SCIENCE PROGRAM
$9 ←λF←λa←λl←λl ←λ1←λ9←λ8←λ5
$9 Cognitive Science Seminar - IDS 237A
$9 Tuesday, November 19, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``Adaptive Planning is Commonsense Planning''
Richard Alterman
Computer Science Division, U.C.B.
A characteristic of commonsense planning is that it is
knowledge intensive. For most mundane sorts of situations
human planners have access to, and are capable of exploiting,
large quantities of knowledge. Commonsense planners re-use old
plans under their normal circumstances. Moreover, commonsense
planners are capable of refitting old plans to novel cir-
cumstances. A commonsense planner can plan about a wide range
of phenomena, not so much because his/her depth of knowledge is
consistent throughout that range, but because s/he can re-fit
old plans to novel contexts.
This talk is about an approach to commonsense planning
called ←λa←λd←λa←λp←λt←λi←λv←λe ←λp←λl←λa←λn←λn←λi←λn←λg. An adaptive planner plans by exploit-
ing planning knowledge in a manner that delays the reduction of
commonsense planning to problem-solving. Key elements in the
theory of adaptive planning are its treatment of background
knowledge and the introduction of a notion of planning by
situation matching. This talk will describe adaptive planning
as it applies to a number of commonsense planning situations,
including: riding the NYC subway, trading books, transferring
planes at JFK airport, and driving a rented car.
----------------------------------------------------------------
UPCOMING TALKS
$9 November 26:Eve Clark, Linguistics, Stanford
December 3:Bernard Baars, Langley Porter, UCSF
----------------------------------------------------------------
ELSEWHERE ON CAMPUS
Jeff Shrager of Xerox PARC will speak on ``Instructionless
Learning'' at the SESAME Colloquium on November 18, 2515 Tolman
Hall, 4:00pm.
The Physics Department is sponsoring a talk by J. J. Hopfield
of CALTECH on Wednesday, November 20 at 4:30pm in 1 Le Conte.
Dr. Hopfield will be speaking on ``Neural Networks.'' A tea
precedes the talk.
∂14-Nov-85 2045 @SU-SCORE.ARPA:cbosgd!packard!ihesa!olaf@seismo.CSS.GOV
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 20:45:08 PST
Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Thu 14 Nov 85 14:52:09-PST
Return-Path: <cbosgd!packard!ihesa!olaf>
Received: from cbosgd.UUCP by seismo.CSS.GOV with UUCP; Thu, 14 Nov 85 17:40:02 EST
Received: by cbosgd.ATT.UUCP (4.12/UUCP-Project/11.09.85)
id AA18330; Thu, 14 Nov 85 16:16:25 est
Date: Thu, 14 Nov 85 15:02:25 cst
From: packard!ihesa!olaf@seismo.CSS.GOV (O I Henjum)
Message-Id: <8511142102.AA16654@ihesa.UUCP>
Received: by ihnp4.ATT.UUCP id AA17591; 14 Nov 85 15:05:48 CST (Thu)
Received: by ihesa.UUCP (4.12/4.7)
id AA16654; Thu, 14 Nov 85 15:02:25 cst
Received: from ihnp4.UUCP by py/garage/packard.DK; 8511142108
To: csd@su-score.arpa, olaf@seismo.CSS.GOV
I realize this letter will probably get mailed to many people who couldn't care less
about it and I apologize to them in advance. However, I simply don't have the E-Mail
addresses for everybody who DOES care to see it.
My new mailing address is:
Olaf I. Henjum
4721 St. Joseph Creek Road #4B
Lisle, IL 60532
Home telephone number: (312) 968-2468
If you want to keep in touch with me, please reply to this msg and I'll collect the
return paths from your messages.
-- Olaf Henjum ("ihnp4!ihesa!olaf"@berkeley)
∂14-Nov-85 2145 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ernie.berkeley.edu
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 14 Nov 85 21:45:35 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 14 Nov 85 21:44:23-PST
Received: from ucbvax.berkeley.edu by SU-SCORE.ARPA with TCP; Thu 14 Nov 85 21:43:34-PST
Received: by ucbvax.berkeley.edu (5.31/1.2)
id AA29649; Wed, 13 Nov 85 10:56:07 PST
Received: by ernie (5.31/5.13)
id AA24751; Wed, 13 Nov 85 10:55:15 PST
Date: Wed, 13 Nov 85 10:55:15 PST
From: karp@ernie.berkeley.edu (Richard Karp)
Message-Id: <8511131855.AA24751@ernie>
To: aflb.local@su-score.arpa, allmsgs@ernie.berkeley.edu,
csfac@ernie.berkeley.edu, csmsgs@ernie.berkeley.edu,
theory-b@ernie.berkeley.edu, theory-f@ernie.berkeley.edu
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley (415)642-0143
The following seminars will be held in the MSRI Lecture Hall
Tuesday, Nov. 19 2:00
Eva Tardos "How to Make Polynomial Algorithms Strongly Polynomial"
Tuesday, Nov. 19 4:00
Joe Traub "Information-Based Complexity"
Thursday, Nov. 21 4:00
Jonathan Buss "Relativized Alternations"
∂15-Nov-85 0734 JF@SU-SUSHI.ARPA bats abstracts
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 15 Nov 85 07:34:16 PST
Date: Thu 14 Nov 85 23:12:48-PST
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: bats abstracts
To: aflb.su@SU-SUSHI.ARPA
Message-ID: <12159366086.14.JF@SU-SUSHI.ARPA>
I now have the abstracts for next week's bats at DEC. They are in
SUSHI:<JF>bats.abstracts
If you cannot conveniently read sushi files, let me know and I will send
you a copy.
Joan
-------
∂15-Nov-85 0733 @SU-SUSHI.ARPA:broder@decwrl.DEC.COM Abstracts for BATS talks at DEC
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 15 Nov 85 07:33:19 PST
Received: from decwrl.DEC.COM by SU-SUSHI.ARPA with TCP; Thu 14 Nov 85 22:31:23-PST
Received: from magic.ARPA (magic) by decwrl.DEC.COM (4.22.01/4.7.34)
id AA26826; Thu, 14 Nov 85 22:27:57 pst
Received: by magic.ARPA (4.22.01/4.7.34)
id AA18287; Thu, 14 Nov 85 22:27:22 pst
From: broder@decwrl.DEC.COM (Andrei Broder)
Message-Id: <8511150627.AA18287@magic.ARPA>
Date: 14 Nov 1985 2227-PST (Thursday)
To: aflb.all@sushi
Cc: pryde@decwrl.DEC.COM, allen%ucsc.CSNET@CSNET-RELAY.ARPA,
terada@cad.berkeley.edu
Fcc: sent
Subject: Abstracts for BATS talks at DEC
Here are the abstracts for the Bay Area Theory Seminar to be held at
DEC-SRC, Friday, November 22, starting at 10 a.m. - Andrei
----------------------------------------------------------------------
10:00 - Lyle Ramshaw (DEC) - Beziers and B-Splines as multiaffine maps
Curves and surfaces that are built up as splines out of polynomial pieces
are fundamental in computer aided geometric design. There is an established
body of theory, associated with the names Bezier, de Casteljau, and de Boor,
for conveniently specifying, evaluating, and manipulating such splines. We
shall redevelop this standard theory in a novel way by exploiting a general
mathematical principle: functions of degree n in one argument are
essentially equivalent to symmetric functions of n arguments that have
degree one in each argument separately. Tackling splines from this new
perspective makes many things simpler. In particular, it gives us a good
system of multivariate labels for the points that arise in spline
constructions. These labels make the geometric relations between the points
so obvious that it becomes straightforward to reinvent the standard
algorithms in this area.
11:00 Anna Karlin (Stanford) - An optimal algorithm for PRAM simulation using
universal hashing
We present a new probabilistic algorithm which simulates T steps of an
arbitrary given PRAM program (where the number of shared variables is
polynomial in the number of processors) in O(T log n) steps on a butterfly,
with probability tending to 1. The algorithm utilizes a log n - universal
class of hash functions.
The previously known best results for simulating T steps of an arbitrary
PRAM program on a bounded degree network are O(T (log n)↑2 log* n) steps in
the deterministic case (nonconstructive) and O(T (log n)↑2) steps, with
probability tending to 1, in the probabilistic case.
An application of the parallel hashing scheme developed will be presented.
(This work was done jointly with Eli Upfal.)
12:00 Lunch (catered by "Picnics in the Park")
1:00 Open problems
1:30 Ketan Mulmuley (U. C. Berkeley) - Parallel algorithms for rank and
matching.
We show that the rank of a matrix over an arbitrary field can be computed in
deterministic 0(log↑2 n) time using a polynomial number of processors. As a
result, many important problems descend in the complexity hierarchy from RNC
to NC. These include basic problems in linear algebra, notably solving a
system of linear equations over an arbitrary field, and many other problems
related to group theory, graph isomorphism, factorization of polynomials.
We shall also give a very simple RNC↑2 algorithm to construct a maximal
matching in a graph. This is an improvement over the previous RNC↑3
algorithm due to Karp and Widgerson.
2:30 - Maria Klawe (IBM - Almaden) - Algorithms for embedding graphs in
multi-layer grids
This talk presents a model for multi-layer printed circuit boards, and a
number of area-efficient algorithms for laying out circuits on such boards.
In some cases we can show that the area used by these algorithms cannot be
substantially reduced. This work significantly improves previously known
results even for a single layer.
(joint work with Alok Aggarwal, David Lichtenstein, Nati Linial and Avi
Wigderson)
∂15-Nov-85 0848 ACUFF@SUMEX-AIM.ARPA Newest batch of Explorers
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 15 Nov 85 08:48:23 PST
Date: Fri 15 Nov 85 02:19:24-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Newest batch of Explorers
To: ksl-lispm@SUMEX-AIM.ARPA, DELANEY@SUMEX-AIM.ARPA, nii@SUMEX-AIM.ARPA,
WASHINGTON@SUMEX-AIM.ARPA, UNRUH@SUMEX-AIM.ARPA
Message-ID: <12159400053.19.ACUFF@SUMEX-AIM.ARPA>
The newest batch of Explorers (5 soon to be 6 and then 7, bringing
the total to 18) is pretty much ready for use. 4 machines will be
located in the lobby of Whelan Bldg. C as soon as their tables arrive
(hopefullly next week), and there are two pool machines in Whelan
A-1105.
Please read the "Getting Started with Explorers at KSL" and related
documents before the one marked "READ FIRST" from TI. In particular,
remember that we are running pre-release software, so please be sure
to let me know of problems.
-- Rich
-------
∂15-Nov-85 0848 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #32
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 15 Nov 85 08:48:50 PST
Date: 15 Nov 85 0637-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #32
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Friday, 15 Nov 1985 Volume 1 : Issue 32
Today's Topics:
Smalltalk vs Actors
Lisp Vectorizable?
----------------------------------------------------------------------
Date: Wed, 13 Nov 85 23:02 EST
From: Henry Lieberman <Henry%OZ@MIT-REAGAN.ARPA>
Subject: Smalltalk vs Actors
I think the remarks made by Schwab and Hendler on Actors vs. Smalltalk
were well done, which is why I didn't feel the need to reply myself.
There are lots of inessential differences, but the major ones are that
actors are designed for parallelism, and permit non-stack control
structures through the use of continuations.
However, Brando seems still confused. The fact that Smalltalk is
implemented on a sequential machine doesn't matter. Actors have in
fact been implemented several times on sequential machines, too. But
the languages handle parallelism very differently. Smalltalk's
parallelism requires a scheduler [one is written in Smalltalk], and
Smalltalk processes must EXPLICITLY relinquish control. This is a
coroutine model, not a parallel one. Actors assume parallel
execution, create parallelism using the future mechanism, and must
explicitly use serializer actors for sequential synchronization. An
actor implementation on a sequential machine must make all
time-sharing completely invisible to the user's program.
Another difference between Actors and Smalltalk is the mechanism for
sharing knowledge between objects. Smalltalk uses classes, subclasses
and instances, borrowing the model from Simula. Actors make no
distinction between classes and instances -- every object can be
considered as a "prototype" for creating new objects. If an object
receives a message that it doesn't understand, it can "delegate" or
forward the request to another object with more general knowledge.
------------------------------
Date: Thu 14 Nov 85 00:27:34-EST
From: Randy Haskins <rh%MIT-EECS@mit-eddie.MIT.EDU>
Subject: Re: PARSYM Digest V1 #31
Date: Tue, 12 Nov 85 13:47:55 est
From: eldridge@EDN-VAX.ARPA (Charles Eldridge)
The speed of LISP is an interesting issue. I would
conjecture that these odd relationships are a consequence
of the irregularity of instructions and memory references
in the execution of LISP applications. In contrast,
vectorized problems are very regularized. It may also be
that vectorizing LISP applications would be contrary to the
high flexibility offered by that language. Vectorizing
numerical applications requires careful hand tailoring of
code in most cases. Where might LISP be hand tailored to
support vectorization? We must look for repeated application
of the same function, for example as in MAPCAR or in a recursive
function. But, in the case of MAPCAR and its relatives, we
may have a complex function to evaluate with each application.
Vectorization thrives on simpler functions that can be implemented
in hardware. In the case of recursion, the flow of control
is unpredictable. We can't see in advance where the recursion
will stop.
Page faulting in LISP is probably a major issue here. It's very
difficult (probably impossible, unless you have a radical compiler) to
keep paging down by the way you write code. If you use lots of
macros, you can achieve a large degree of inline-coding, with the
disadvantage that you have to recompile large amounts of code with
each change. (You could develop with DEFUNs, and deliver with
DEFSUBSTs or DEFMACROs to get around this. Of course, this is less
space-efficient...) My understanding of vectorization isn't all that
great, but from what I know of it, it seems that MAPCAR-class
primitives would be the most obvious uses. Perhaps the ZetaLisp LOOP
macro (maybe some invocations of LOOPing on lists can use MAPCAR) and
DO constructs could use vectorization, although one has to be careful
that a given iteration doesn't depend on ANY side-effects of previous
iterations. For this sort of reason, I would expect that recursion
would be right out of there for vectorization. I don't use much
recursion since the general features of ZetaLisp heavily discourage
it. I suppose another good use would be things like BITBLT, which is
used for copying 2-D array portions around to other array portions.
(Lisp Machine displays depend heavily on this, so it is microcoded.)
Since strings are implemented as arrays of characters, copying them
around and capitalizing and things like that could be vectorized.
Hmm, maybe there are applications for vectorization. Any other ideas?
Random
------------------------------
End of PARSYM Digest
********************
∂15-Nov-85 0918 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 15 Nov 85 09:18:50 PST
Date: Fri 15 Nov 85 09:07:44-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch
To: faculty@SU-SCORE.ARPA
cc: library@SU-SCORE.ARPA, maslin@SUMEX-AIM.ARPA
Message-ID: <12159474389.20.RICHARDSON@SU-SCORE.ARPA>
There will NOT be a CSD lunch on Tuesday, November 19. The weekly lunch
will resume on Tuesday, November 26.
-------
∂15-Nov-85 0921 JJW MJH-LispM news
To: MJH-LispM@SU-AI.ARPA
I've created a mailing list for broadcasting information to users of the
Symbolics Lisp Machines in MJH. To mail to this list, use the address
MJH-LispM@SAIL. There is a similar list called KSL-LispM for users of
the machines owned by KSL at Welch Road. Some people may want to be on
both of these lists.
Here's some recent news about our Lisp Machines, which most of you no
doubt already know.
1. We have a fifth machine in the building, a 3640, and are scheduled to
get a sixth one soon. The new machine is called "Frivolous". It is
currently in MJH 433, the 4th floor machine room, but will be moved to
the Formal Reasoning group's area in the near future. Because of its
small disk, file space on Frivolous is fairly limited.
2. You can send hardcopy text output to Boise from any of the MJH 3600s by
including the form (load "C:>weening>boise.bin") in your init file. It
is no longer necessary to set the default printer individually; it has
been made a default for everyone in the namespace data for the site.
Rich Acuff at KSL is working on Imagen support and we will be able to
get a copy of that when it is available. Dover printing is pretty much
out of the question for now, because it uses the PUP protocol.
3. The "secure subnets" list in the namespace has been fixed so that you
should now be able to open TCP/FTP connections from any Stanford machine
to any of the MJH (or KSL) Lisp Machines.
∂16-Nov-85 0750 ullman@su-aimvax.arpa Re: another paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 07:50:49 PST
Received: by su-aimvax.arpa with Sendmail; Fri, 15 Nov 85 20:00:48 pst
Date: Fri, 15 Nov 85 20:00:48 pst
From: Jeff Ullman <ullman@diablo>
Subject: Re: another paper
To: maier%oregon-grad.csnet@CSNET-RELAY.ARPA, nail@diablo
Well I meant three vowels in a row NOT ALL DISTINCT.
Sorry you missed that point David.
∂16-Nov-85 0751 ark@SALLY.UTEXAS.EDU Re: another paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 07:51:47 PST
Received: from sally.UTEXAS.EDU by su-aimvax.arpa with Sendmail; Fri, 15 Nov 85 21:41:57 pst
Date: Fri, 15 Nov 85 23:35:42 cst
From: ark@SALLY.UTEXAS.EDU (Arthur M. Keller)
Posted-Date: Fri, 15 Nov 85 23:35:42 cst
Message-Id: <8511160535.AA03224@sally.UTEXAS.EDU>
Received: by sally.UTEXAS.EDU (4.22/4.22)
id AA03224; Fri, 15 Nov 85 23:35:42 cst
To: nail@SU-AIMVAX.ARPA
Subject: Re: another paper
This exchange reminds me of the lesson Jeff Ullman once tried to teach me
about doing research. Come up with a statement you think is true. Try
to generate counterexamples while you try to prove it. Ask your friends
for counterexamples. When you find a counterexample, extend your hypothesis
to exclude the counterexamples. It's not so often that you can actually
watch Jeff in action using this very technique, but those of us on this
mailing list are being treated to a view of Jeff in action. I propose
to assist the progress in this problem by doing research. That is, I will
use the best source of last names that I have handy, the Greater Austin
Residence White Pages a.k.a. the Phone Book. Perhaps someone like Mike
Lesk could do this using some online version of the White Pages, after
all he's at Bellcore. The first page has two examples (adjacent in fact)
of the case David Maier reported: Abijaoude and Abijaoudi. A sequential
search through the phone book would be quite lengthy, so I used one
important techique, variation on an existing counterexample. So I looked
up Meier. There were 31 entries, plus one for Meiers. Particularly
appropriate was the address for one Paul Meier: 11504 Ruffled Grouse.
On the other hand, reminding me of the sign I saw in Tel Aviv in 1982
("Ullman Shoes") was the address for J B Meier: 10410 Broken Shoe Trail.
If the next problem will be to find three adjacent vowels, with two
adjacent ones matching, let me report this entry on page 313 (a palindrome):
Massoud MINOOI.
To close, I present the following name for your inspection: COUIE Edward D.
Arthur
∂16-Nov-85 0752 maier%oregon-grad.csnet@CSNET-RELAY.ARPA Re: another paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 07:52:35 PST
Received: from CSNET-RELAY.ARPA by su-aimvax.arpa with Sendmail; Fri, 15 Nov 85 18:17:40 pst
Received: from oregon-grad by csnet-relay.csnet id aa04973; 15 Nov 85 20:59 EST
Received: by ogcvax.ogc.uucp (4.12/OGC←1.2)
id AA07083; Fri, 15 Nov 85 17:05:59 pst
Date: Fri, 15 Nov 85 17:05:59 pst
From: "Prof. David Maier" <maier%oregon-grad.csnet@CSNET-RELAY.ARPA>
Message-Id: <8511160105.AA07083@ogcvax.ogc.uucp>
To: nail@su-aimvax.ARPA
Subject: Re: another paper
Ahem
david mAIEr
∂16-Nov-85 0757 ACUFF@SUMEX-AIM.ARPA Re: MJH-LispM news
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 07:57:32 PST
Date: Fri 15 Nov 85 12:41:49-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Re: MJH-LispM news
To: JJW@SU-AI.ARPA, MJH-LispM@SU-AI.ARPA
In-Reply-To: Message from "Joe Weening <JJW@SU-AI.ARPA>" of Fri 15 Nov 85 09:21:00-PST
Message-ID: <12159513361.70.ACUFF@SUMEX-AIM.ARPA>
KSL-LispM is directed to ALL users of KSL Symbolics or TI lisp machines,
not just Welch Rd. There is a list called Whelan-LispM-Users which does
that.
-- Rich
-------
∂16-Nov-85 0759 NEALE@SU-CSLI.ARPA
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 07:59:04 PST
Date: Fri, 15 Nov 1985 14:33 PST
Message-ID: <NEALE.12159533770.BABYL@SU-CSLI.ARPA>
From: NEALE@SU-CSLI.ARPA
To: folks@SU-CSLI.ARPA
On Tuesday Nov. 19, MENTAL LIMOUSINE (Stephen Neale, Sami Shaio,
Susana Wessling &c.) will be performing at
The VIS club, 628 Divisadero, S.F.
For just $2 you get to see THE VISIT (Another Stanford all original
band), BURNING WITCHES (a feminist thrash-punk band---really wild), as
well as MENTAL LIMOUSINE playing their own brand of Indo-European
dirge jazz-punk. Come along, have a ball. (Performance starts at 10:00 pm).
∂16-Nov-85 0800 ACUFF@SUMEX-AIM.ARPA KSL-3640-7 down
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 08:00:36 PST
Date: Fri 15 Nov 85 16:14:37-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: KSL-3640-7 down
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12159552100.79.ACUFF@SUMEX-AIM.ARPA>
47 has popped it's tube, and will probably not be worked on until
Monday.
-- Rich
-------
∂16-Nov-85 0759 RICHARDSON@SU-SCORE.ARPA General Faculty Meeting
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 07:59:17 PST
Date: Fri 15 Nov 85 11:08:01-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: General Faculty Meeting
To: faculty@SU-SCORE.ARPA
Message-ID: <12159496287.20.RICHARDSON@SU-SCORE.ARPA>
There will be a general faculty meeting on Tuesday, December 10 at 1:30 pm.
Please send any items that you would like to be included on the agenda to
Richardson@score.
-------
∂16-Nov-85 0801 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #33
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 08:01:42 PST
Date: 15 Nov 85 2009-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #33
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Saturday, 16 Nov 1985 Volume 1 : Issue 33
Today's Topics:
Third PARSYM Survey: Hardware for Parallel Symbolic Computing
----------------------------------------------------------------------
Date: Fri, 15 Nov 1985 20:01 PST
From: DAVIES@SUMEX-AIM.ARPA
Subject: Third PARSYM Survey
Hardware for Parallel Symbolic Computing
The Third PARSYM Survey is designed to inform the PARSYM readership
about computer hardware systems that are being used or developed for
parallel symbolic computing.
Some research groups are using multiprocessor hardware -- obtained
commercially, acquired under special arrangement with the manufacturer,
or developed locally. Others are simulating multiprocessing on
uniprocessors, such as Lisp machines. Still others are connecting
multiple uniprocessors using LANs or specialized communication hardware.
Let us know what category you fall into -- or if I need to add more
categories -- and what the general nature of your hardware setup is.
There is an intentional ambiguity in this survey between hardware to
support research and hardware as the end result of research. Since
the field and the available hardware are so new, it's hard to draw the
line between "commercial" and "experimental" hardware. We would like
to hear about both.
Please provide a brief summary of your project, in case others don't
know about it. If you've already described your project to PARSYM,
you'll be forgiven if you don't repeat yourself. If you wish to
describe your software environment in order to clarify the
capabilities of your hardware, please do. You may, however, want to
save the software details for a later survey, which will specifically
address software environments.
When I began putting this survey together, I thought it would be easy
to answer, compared to the last one on data abstractions, which was
rather technical. Now this one looks rather daunting, but I hope that
won't discourage potential respondents from telling us about their
hardware. If you don't have time to answer in full, please spend a
few minutes to fill in the first part of the survey.
Thanks go to Jay Glicksman (AI&DS), who wrote much of the
questionnaire, and Bruce Delagi (Stanford), who offered useful
comments.
!
The Third PARSYM Survey: Computer Hardware
(Reply to PARSYM-Survey@SUMEX-AIM.ARPA)
Part I (Easy)
What computer hardware are you using or developing?
What are its components (processors, memory) and how many; how do the
processors and memory communicate?
SIMD/MIMD? Shared memory or distributed memory?
What model of concurrency are you investigating with this system?
What would you like to see in your next hardware system?
Part II (Optional, for extra credit)
0. Project summary:
What model of concurrency (e.g., dataflow, communicating sequential
processes, actors, futures, etc.) is your work based on? What
language, if any, are you using in your work?
1. Architectural classification:
SIMD or MIMD?
2. Processing elements:
Describe each processor in the system in terms of type (e.g., 68000
equivalent, Lisp machine, custom), "power" (e.g., in MIPS or relative
to a Vax or 68000), and memory size. If the processors are simulated
then also describe the uniprocessor and mechanism for simulation. If
the processors in the system are not of uniform type then describe
each type and their relationship to each other.
How many processors are there in the minimum and maximum configurations?
How many are you currently using?
3. Memory system:
Describe how memory is distributed and accessed in the system. Shared
memory or distributed memory? Is there a single address space or does
each processor have its own address space? What sort of caching is
employed, if any: snoopy, write-through, or something else? What
sizes are the caches?
What are the minimum and maximum amounts of memory? How much are you
currently working with?
4. Communication system:
How are processors connected to each other and to memory? Describe in
terms of topology (e.g., tree, systolic array, pipe, grid), switching
type (e.g., LAN, bus, Butterfly switch), and throughput (e.g., bus
transmission rates, time to access memory on remote nodes, time to
broadcast a message to all nodes).
5. Synchronization:
What hardware mechanisms does the system supply to support
synchronization?
6. Pragmatics
Is your system geared towards either specific programming languages or
applications?
Is the hardware of your system generally available or, if custom-made,
likely to be available in future?
If you're now using a multiprocessor system, how does the architecture
of your development system correspond to your research target
architecture?
What are the advantages of your hardware setup, particularly for the
problems you are investigating? What are the disadvantages? Is there
a system that would better meet your needs?
------------------------------
End of PARSYM Digest
********************
∂16-Nov-85 0805 PATASHNIK@SU-SUSHI.ARPA Upcoming AFLB canceled
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 08:05:45 PST
Date: Fri 15 Nov 85 12:02:50-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: Upcoming AFLB canceled
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12159506266.7.PATASHNIK@SU-SUSHI.ARPA>
It turns out that Ketan Mulmuley is giving the same talk at BATS on
Friday, Nov 22 that he was to give at the upcoming (Nov 21) AFLB.
Consequently his AFLB talk is canceled, and unless another speaker
volunteers there will be no AFLB on the 21st.
--Oren
-------
∂16-Nov-85 0808 @SU-SCORE.ARPA:ullman@su-aimvax.arpa CS UG program update
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 08:08:22 PST
Received: from su-aimvax.arpa by SU-SCORE.ARPA with TCP; Fri 15 Nov 85 20:26:50-PST
Received: by su-aimvax.arpa with Sendmail; Fri, 15 Nov 85 20:26:26 pst
Date: Fri, 15 Nov 85 20:26:26 pst
From: Jeff Ullman <ullman@diablo>
Subject: CS UG program update
To: faculty@score
The Engineering undergraduate council approved the CSUG program,
except for the detail of the exit requirement, which we have
been informed must be considered by the Committee on Undergraduate
Studies. In the process of negotiation, several changes have been
made, and I would like to outline these.
1. The UGC agreed to allow CS to trade 5 units of Science for 5
of Math. Our new program has a required 12 units of science,
and 28 of math, 10 "engineering basics" (CS 106 + E 40 = electronics),
and 44 units of CS. The total, 94 units, is 8 fewer than the
proposal of September.
2. After a hard struggle, they approved the use of Psych 102, 106, and 108
as science options.
3. We dropped the 6 units of "CS electives" from the previous proposal.
Some of the courses were transferred to "Math electives", below.
4. After a close vote, the committee decided to drop the Math 120
(algebra) requirement, but put it in a group of math electives designed
to beef up our math requirement, and thereby get the science + math
total up to >= 38. Students are required to choose two from:
Math 44, Math 120 or 120S, Stat 110 or 116, and CS 135,237A, and 260.
The UGC suggested that it would approve OR 151 (which was formerly
a "CS elective" as a math elective, and I assume the CSD curriculum
committee will add that to the list.
The faculty senate has decided that it should approve our
program, so we shall have to bring it before the CUS and then the
senate.
The UGC has also endorsed our intent to develop a "numerical linear
algebra course, and there was indication that if we offered it,
the course would be required by other departments as well.
---Jeff
∂16-Nov-85 1209 BSCOTT@SU-SCORE.ARPA Locks
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Nov 85 12:09:05 PST
Date: Sat 16 Nov 85 11:47:43-PST
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: Locks
To: CSD@SU-SCORE.ARPA
cc: BScott@SU-SCORE.ARPA
Message-ID: <12159765658.17.BSCOTT@SU-SCORE.ARPA>
If you have an office in MJH, be sure your door is actually locked when you
leave. When the locks were changed a few of the locking mechanisms may have
been inadvertently adjusted so that when the doors are closed they are not
locked.
Betty
-------
∂17-Nov-85 0623 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #34
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 17 Nov 85 06:23:01 PST
Date: 16 Nov 85 1340-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #34
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Saturday, 16 Nov 1985 Volume 1 : Issue 34
Today's Topics:
Actors ?= Smalltalk
A PARSYM challenge: MIMD vs SIMD
----------------------------------------------------------------------
Date: 15 Nov 85 (Fri) 11:57:08 EST
From: Keiji Kanazawa <kgk%brown.csnet@CSNET-RELAY.ARPA>
Subject: Actors ?= Smalltalk
> With all due respect to those involved, isn't the whole Actors
> paradigm essentially at one with object-oriented paradigms a la
> Smalltalk, which have been around for quite some time now?
Scheme and FP are both applicative programming languages (after a
fashion). Nice... But I don't see that you'd want to say that they're
essentially at one.
If there is a textbook 20 years from now, and it classified languages as
'declarative', 'applicative', 'object-oriented', yes, it may well put
Smalltalk together with Prelude/Act-1/2/3. I think few people would
disagree; it's more or less a trivial point.
But for that very reason, it's hard for me to think of Actors any
longer as anything but a parallel computation model. Who cares if
it's object oriented?
It seems implied ("which have been around for quite some time now")
that Actors came long after Smalltalk did. This is not the case. I
think original work on PLASMA came as early as 1975.
> A careful reading of the postings of Karl and Jim points out that they
> are, in fact, comparing object-oriented *paradigms* with
> message-passing *implementations*.
Importantly, parallelism has been embodied in the Actor model from
those very beginnings. The two are inseparable; it's not a question of
implementation. It had to do with the idea that a Society of Agents
could cooperate to solve problems.
Finally, the Actor model seems broader in scope than other object
oriented languages. It's conceivable that a large Actor system,
encompassing, let's say, the whole state of California, would include
a Smalltalk workstation as one of its many actors. The reverse
situation is not addressed in the vanilla Smalltalk model.
Furthermore, such a system illustrates another point - that the Actor
universe is one in which, potentially, at any particular point in
time, the whole state of the world is not completely known or
knowable. This may not be a solved problem for Actors; but it is not
addressed at all by Smalltalk, and it isn't about implementation.
Keiji Kanazawa
------------------------------
Subject: A parsym challenge: MIMD vs SIMD
Date: 16 Nov 85 11:02:48 EST (Sat)
From: Bradley C. Kuszmaul <bradley@THINK.COM>
This submission argues that SIMD is just as good as MIMD and concludes
with a challenge to the parsym readership.
I propose the following hypothesis about parallel computing:
`All real applications for parallel computing can run as well on a
SIMD machine as on a MIMD machine'.
Now before you say `like wow, this guy is crazy', let me finish...
The following discussion assumes that you know what I mean by MIMD,
SIMD, and how MIMD and SIMD machines are usually programmed. I will
define my terms a little more carefully later in this document.
It is clear that in some sense MIMD machines are more powerful than
SIMD machines, since a MIMD machine can simulate a SIMD machine by
simply having every processor do the same thing. However, if we
accept my hypothesis, then it might very well be the case that we
would rather build SIMD machines for a variety of reasons (such as
cost and the difficulty of designing the machines).
The Argument Against SIMD
There are several programming languages which, as far as I know, are
relatively difficult to implement on SIMD machines because the
semantics of the language requires that each processor be doing a
different thing at the same time. One example of this would be a
functional programming language (e.g. pure lisp), in which case every
processor might be responsible for evaluating one subexpression, and
depending on the implementation, you might see and-parallelism,
or-parallelism or both. For example, when evaluating the expression
(+ (F 1) (G 2))
it seems reasonable to evaluate (F 1) and (G 2) in parallel on
different processors since the addition operator is strict; it will
need both of its arguments in order to finish evaluating. (When
exploiting parallelism in the IF statement we must be more careful
because one of the `arms' of the IF won't be used.) The problem here
is that the evaluation of (F 1) and (G 2) may be totally different
(for example if (F 1) involves lots of floating point operations while
(G 2) involves lots of BIGNUM operations). This situation clearly
calls for a MIMD machine, so that one processor can be doing a
floating point operation while another does a bignum operation.
The Argument Against MIMD
Now that I have presented what I view as the fundamental argument
against my hypothesis, let me explain why the hypothesis might still
be true. The hypothesis calls for `real applications'. A programming
language is not a real application. If someone implements a simulator
for systolic arrays written in pure lisp, then the full power of the
pure lisp implementation is being wasted, since the systolic array
could have been implemented efficiently on a SIMD machine. Thus the
hypothesis is that there are no actual applications that someone
really needs which can not be implemented efficiently on a SIMD
machine. The standard application for MIMD machines is simulating
other MIMD machines, which is circular, and I don't buy.
Examples of Applications for which SIMD Wins
Example 1: Finite element analysis. In this case there are a set of
elements connected in a graph. The analysis involves each element
communicating with its neighbors, and then performing some state
change based on that communications. The communication and state
change program which is run on each element is almost independent of
which element is being worked on. In a SIMD machine every processor
would simulate one of the finite elements, and all the processors
would be kept busy doing useful work all the time (and we can thus
conclude that the implementation is efficient).
Example 2: Finding a minimal PLA for a given set of boolean equations.
The implemention for a SIMD machine is that every processor simulates
one possible PLA. The program to simulate the PLA is the same for
every PLA (since the description of the PLA can be treated as data).
It is possible to object to this example on the grounds that the
description of the PLA is part of the program to simulate the PLA, and
that we are describing a MIMD machine because each processor simulates
one PLA.
Post Discussion Definitions
So now for the interesting question of what I mean by SIMD and MIMD.
There is a spectrum of possible machines. The problem in defining our
terms is that I could argue that a network of M68000's clocked by a
common signal is SIMD:
There are N processors, each of which has some local data, some of
which tells the program how to run. Each processor understands
exactly one instruction, the EVAL instruction which interprets one
opcode of the local data. Since there is only one instruction we can
represent the instruction with no bits, and we need only to distribute
a common clock to all of the processors.
My claim is that the distinction between SIMD and MIMD is subjective,
and the difference is how you write programs for them.
You are in MIMD mode if you write a program which runs on a single
processor which communicates with other processors.
You are in SIMD mode if you write a program which is to be executed on
all processors at the same time.
These distinctions are still subjective... oh well.
A Challenge
Can anyone propose real applications which can not be implemented
efficiently on a SIMD machine?
Please send entries to parsym to be posted and to me (see my address
below) so I can have a chance to argue that it really can be
implemented efficiently.
Please include a description of the application and a strategy for
efficient implemention on a MIMD machine, and if you want you can
include an explanation of why you believe that it can not be
efficiently implemented on a SIMD machine.
In order to set the ground rules a little more firmly, I allow you to
use any MIMD machine but require that your application have an
unbounded amount of parallelism (as a function of the size of the
problem). I will use a machine like the connection machine as my
canonical example of a SIMD machine. If I can keep my connection
machine processors busy `most of the time' doing useful computation
towards solving your problem than I will claim that the application is
an instance which supports my hypothesis.
Let's see those applications come pouring in...
-Brad
bradley@think.arpa
or
bradley@think.com.arpa
or
bradley@think.uucp
------------------------------
End of PARSYM Digest
********************
∂17-Nov-85 1850 ullman@su-aimvax.arpa Re: another paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Nov 85 18:50:28 PST
Received: by su-aimvax.arpa with Sendmail; Sun, 17 Nov 85 14:51:17 pst
Date: Sun, 17 Nov 85 14:51:17 pst
From: Jeff Ullman <ullman@diablo>
Subject: Re: another paper
To: ark@SALLY.UTEXAS.EDU, nail@diablo
1. I *think* Papadimitriou is an anomaly because in the original
Greek, it does not have three vowels in a row (I may be wrong sbout
this--Christos??) The same probably applies to Abijaoude, where
the ou is a transliteration of one vowel.
As for Couie, I meant *exactly* three vowels in a row, not
three or more. Sorry you missed this point, Arthur.
2.
∂17-Nov-85 1851 LANSKY@SRI-AI.ARPA PLANLUNCH reminder -- Jeff Finger, 11am
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 17 Nov 85 18:51:24 PST
Date: Sun 17 Nov 85 18:49:03-PST
From: LANSKY@SRI-AI.ARPA
Subject: PLANLUNCH reminder -- Jeff Finger, 11am
To: planlunch-reminder.dis: ;
EXPLOITATION OF CONSTRAINTS IN DEDUCTIVE DESIGN SYNTHESIS
Jeff Finger (JFINGER@SUSHI)
Stanford University
11:00 AM, MONDAY, November 18
SRI International, Building E, Room EJ228 (new conference room)
The talk will cover two related topics in deductive design synthesis:
(1) efficiency gained by reasoning forward from subgoals, and
(2) advantages and disadvantages of using a declarative representation
for partially completed designs.
The first part of the talk gives the deductive framework for capturing the
following intuition:
Suppose I have decided that X and Y and to be true of my
design. Perhaps I should think about what else X and Y imply
about the design, say Z. Otherwise, I might waste time
trying to complete the design process by making decisions
that have *already* been ruled out by X and Y, for example,
NOT(Z).
The conditions that X and Y imply (called "necessary constraints" or "NC's")
are found via reasoning forward from subgoals. We show how NC's of a
subgoal can be used to prune the design space either by preventing some
impossible possibilities from ever being generated or by providing a quick
means of filtering bad choices. In terms of resolution, the above use of
NC's corresponds to the rather counterintuitive notion of allowing
OR-INTRODUCTION on clauses in the set of support. We will also discuss
inheritance of NC's from goal to subgoal and the relation of finding NC's to
that of checking consistency of partially completed designs.
The second part of the talk deals with declarative representation of
partially completed designs. Deductive design systems such as QA3 or Manna
and Waldinger's reify the design as a single term in the logic.
However, it is difficult to express many sorts of constraints on partially
completed designs as a single term. Examples include two actions in an
unspecified order, or the constraint that Action A takes place less than 3
seconds or more than 8 seconds after Action B. We present a system called
RESIDUE in which we build up the design as a set of facts we are willing to
assume about of the design. Using facts rather than a single term, we can
make finer-grained decisions, avoiding unwitting commitments that might
result in unnecessary backtracking. In addition, forward reasoning on
subgoals (as in the first portion of the talk) may be done directly on the
set of facts.
-------
-------
∂17-Nov-85 1858 BRESNAN@SU-CSLI.ARPA Morphology, Syntax, Discourse Interactions
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 17 Nov 85 18:58:05 PST
Date: Sun 17 Nov 85 17:26:44-PST
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: Morphology, Syntax, Discourse Interactions
To: folks@SU-CSLI.ARPA
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
This Thursday, November 21, Carolyn Coleman will present her work
on Reflexives in Kunparlang in the CSLI conference room at 10:00
a.m. Everyone interested in lexical rules, lexical morphology,
and the semantics of reflexive pronouns is invited.
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
``Morphological Structure of Kunparlang Verbs''
Kunparlang verbs are extremely complex morphologically. They
cross- reference Subject and Object functions, incorporate nominal
roots, use `applicative' derivational morphology, carry modal,
directional and aspectual affixes, and inflect for Tense and Mood.
There are two levels of hierarchical morphological structure,
(i) The stem, which carries all morphology having compositional
semantics.
(ii) The lexical base, which caries all semantically idiosyncratic
morphology.
Kunparlang verbs undergo two types of reflexive operation which
have a partially complementary distribution and which have different
semantic effects on the verbs to which they apply. With the first
reflexive operation the reflexive subject is always an Actor; with the
second the reflexive subject may be an Undergoer. The second reflexive
operation has a range of meanings which match those of
mediopassive constructions in other languages as well as the
reflexive reading. Both reflexivizing operations are derivations that
apply at the level of the lexical base; given that they have the same
morphological status, there is a problem of how to semantically
characterise them in a manner that will clearly show the semantic
similarities and differences between them. --Carolyn Coleman
-------
∂17-Nov-85 1859 ACUFF@SUMEX-AIM.ARPA Bug Reporting from Explorers
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 17 Nov 85 18:59:25 PST
Date: Sun 17 Nov 85 16:30:36-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Bug Reporting from Explorers
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12160079299.63.ACUFF@SUMEX-AIM.ARPA>
If you'd like to report a bug on an Explorer and include a stack
trace in the report (generally a good idea if you can get one), you
can do the following: (1) use C-M from the debugger to get into Zmacs
with lots of debugging info already put into the buffer, (2) fill in
your comments, (3) write the file to your favorite mail host (eg. Sumex
or Diablo), (4) login on the host you wrote the bug report to and send
it to me. This is necessary because the Explorers don't speak TCP
SMTP (as yet) or PUP MTP, and so can't send mail directly to any
Stanford hosts.
-- Rich
-------
∂18-Nov-85 1012 WECHSLER@SU-CSLI.ARPA XenoneX
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 18 Nov 85 10:12:12 PST
Date: Mon 18 Nov 85 10:03:10-PST
From: Stephen Wechsler <WECHSLER@SU-CSLI.ARPA>
Subject: XenoneX
To: folks@SU-CSLI.ARPA
The techno-formula music group XENOFILE (Steve Wechsler,
Linguistics Dept.; Elizabeth Dykstra, X-ist theorist;
Jim Shearer, Mathematics, UCB; and others)
will team up with the NYC-based post-modern
dance troupe PALINDROME to present excerpts from
their new collaborative work "XENONEX". Coordinates:
Time = Saturday, Nov. 23rd at 10:00 pm
Space = THE LAB (1805 Divisadero at Bush, S.F.)
A party till 3 am follows (w/ DJ Raoul!); a $5 cover will benefit
THE LAB, "a cooperative laboratory for the arts."
-------
∂18-Nov-85 1018 INGRID@SU-CSLI.ARPA Symposium on AI
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 18 Nov 85 10:18:51 PST
Date: Mon 18 Nov 85 10:08:49-PST
From: Ingrid Deiwiks <INGRID@SU-CSLI.ARPA>
Subject: Symposium on AI
To: SU-Bboards@SU-CSLI.ARPA, Folks@SU-CSLI.ARPA
ANNOUNCEMENT
Soto Symposia on Artificial Intelligence
----------------------------------------
A series of three symposia on AI will be held in the Soto Lounge,
Wilbur Hall, the first three Mondays in November, at 7 p.m. These
symposia are intended to inform Stanford students and others who are
interested about the nature of AI, its prospects, and the intellectual
and social issues to which it gives rise.
The first two symposia were held during the last couple of Mondays.
The third one is scheduled for today:
Monday, November 18, 7 p.m.
"Star Wars and Computation"
John McCarthy Professor of Computer Science, Stanford
David Redell DEC Research Laboratory
and possibly others
This symposium will begin with short talks by the speakers, followed
by plenty of time for vigorous interchanges among the speakers and
with members of the audience.
Soto is the first dormitory in the Wilbur complex that one comes to
when walking out Escondido from the Undergraduate Library.
----------------------------------------------------------------------
<--UGLI Escondido Rd.
----------------------------------------------------------------------
xxxxxxxxxxxxxx X XXX XXX X
Soto --> X Wilbur X
Stern Hall X X
xxxxxxxxxxxxxx X Hall X
X X
X XXX XXX X
-------
∂19-Nov-85 0827 @SU-SUSHI.ARPA:RUTENBURG@SU-SCORE.ARPA ICALP
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 08:27:19 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Mon 18 Nov 85 17:51:17-PST
Date: Mon 18 Nov 85 17:51:19-PST
From: Vladislav Rutenburg <RUTENBURG@SU-SCORE.ARPA>
Subject: ICALP
To: aflb.local@SU-SCORE.ARPA
Message-ID: <12160356138.22.RUTENBURG@SU-SCORE.ARPA>
Does anybody have the call for papers for the ICALP in France in July or
know who is on the organizing committee and the phone numbers to contact them?
we seem to have missed the deadline.
-------
∂19-Nov-85 0843 @SU-CSLI.ARPA:BrianSmith.pa@Xerox.ARPA A day's mail lost
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 08:43:17 PST
Received: from Xerox.ARPA by SU-CSLI.ARPA with TCP; Tue 19 Nov 85 08:33:24-PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 NOV 85 08:38:07 PST
Date: 19 Nov 85 08:26 PST
From: BrianSmith.pa@Xerox.ARPA
Subject: A day's mail lost
To: ISL↑.pa@Xerox.ARPA, Folks@SU-CSLI.ARPA, Wendy Hansen
<P.PURPLE@[36.48.0.5]>, lamping@Su-sushi.ARPA, Berlin@MIT-XX.ARPA,
Borning@Washington.ARPA, Estrin@MIT-XX.ARPA, Gould.pa@Xerox.ARPA,
Ornstein.pa@Xerox.ARPA, Suchman.pa@Xerox.ARPA, TW@SU-AI.ARPA,
Zilles.IBM-SJ@CSNet-Relay.ARPA, gnelson@DECWRL.DEC.COM,
redell@DECWRL.DEC.COM, PARC-CSLI!chapman@parcvax.ARPA
cc: BrianSmith.pa@Xerox.ARPA
Reply-to: BrianSmith.pa@Xerox.ARPA
Message-ID: <851119-083807-1465@Xerox>
Due to a software foul-up, I have lost all mail received since about
11:00 yesterday morning. If you sent anything important, could you send
along another copy?
Many thanks
Brian
∂19-Nov-85 0845 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #35
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 08:45:05 PST
Date: 18 Nov 85 0912-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #35
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Monday, 18 Nov 1985 Volume 1 : Issue 35
Today's Topics:
SIMD vs. MIMD (2 messages)
Smalltalk vs. Actors
Survey on Data Abstractions
Seminar: Multilisp (MIT)
[As you've probably noticed, PARSYM is very active at the moment.
There are three major threads: the recently initiated discussion of
SIMD vs. MIMD, the waning discussion of Smalltalk vs. Actors, and the
ongoing PARSYM surveys. So as not to distract from the
reader-initiated discussions, the hardware survey responses are
temporarily being queued for a future issue. One survey response has
been received so far (on Berkeley's Aquarius multiprocessor, from
fagin@dali.berkeley.edu) and others are eagerly awaited. -- BD]
----------------------------------------------------------------------
Date: Saturday, 16 November 1985 20:45-PST
From: coraki!pratt at su-navajo.arpa (Vaughan Pratt)
Subject: SIMD vs. MIMD
I agree with Brad about SIMD vs. MIMD being a matter of level. Abstracting
away to the n-th degree, as mathematicians are wont to do, a clean example
of this principle is the expression L**n, denoting the concatenation of
n copies of the language L with itself. The SIMD interpretation of this
is that all n copies of L are the same language. Going down a level and
looking at individual strings in L**n, we find that up to n different
strings have been chosen from the n copies of L, which looks more like
MIMD behavior. (That may be *too* abstract for some: as executed
programs are fond of asking, who's in charge here?)
Another key observation Brad makes is that one machine's data is
another's instruction. This too shows how dependent the SIMD/MIMD
distinction is on the level of abstraction. MIMD can become SIMD when
the MI part turns into a piece of the MD part.
Finally I agree fully with Brad's claim that it is the programmer's
level that matters. My own reason for taking this position is economic:
programs either written or executed (the distinction is not important
for this argument) by people cost a fortune compared to those written
or executed by machines. If you have SIMD at one level and MIMD at
another, you will save a bundle by arranging things to put the
programmer and SIMD at the same level, on the premise that SIMD
software is cheaper than MIMD software. (I'm happy to enter into a
debate on that premise if there's anyone out there that doubts it.)
-v
------------------------------
Date: Monday, 18 November 1985 07:36-PST
From: Sal Stolfo <sal at CS.COLUMBIA.EDU>
Subject: PARSYM Digest V1 #34
SIMD machines do have certain severe limitations which make MIMD
processing the processing mode of choice. SIMD machines (at the risk
of appearing overly general) require that the data set being processed
(and of course distributed to concurrent PE's) comprises data objects
of the same size, shape and extent. Therefore, concurrent lock-step
instructions can be written with the assumption that the data being
manipulated at a PE is of the exact same type.
Here is a simple operation that blows this out of the water:
Distribute a set of arbitrary first order literals to a set of PE's,
one literal per PE.
Broadcast a single first order GOAL LITERAL to all PE's and execute
logical unification between the locally stored literal and the
broadcast literal.
------------
For a MIMD processor, this operation is straightforward and quite simple.
For an SIMD processor, it is much more problematic, not to mention an
horrific task to program in SIMD mode.
The problem arises when the first order terms in each locally stored
literal varies in type. A logical variable appearing in the broadcast
literal may indeed have to be compared and bound to a constant,
another variable in the locally stored literal, or worse a first order
term which may include variables of course.
Think of the different tests and branches that would need to be issued
from the control processor to the SIMD processor to account for every
possible type of first order term encountered.
I believe it is quite possible to implement this operation in SIMD
mode, but I also strongly believe that the SIMD processor will not
outperform an MIMD processor. Indeed, for certain anomolous cases we
can invent, the SIMD processor will probably be slower that a
sequential processor working on the same data set.
One other issue to be carefully studied here for this operation. Most
of the SIMD processors I am aware of comprise a very limited memory at
each PE. Logical unification has the nasty side effect of producing
resolvents which are "larger" than the two unified parent literals.
Consider unifying:
P(x1,x2,...,xn)
P(f(x0,x0),f(x1,x1),...,f(xn-1,xn-1))
where P is a first order predicate symbol,
xi is a variable
f is a binary skolem function
What result do you get if you use a "string or token" representation
for literals? This is really nasty.
Of course, a list representation is necessary to unify and store the
result. The SIMD processor therefore requires list representations,
and garbage collection. It is safe to assume that the literals being
operated upon will of course span across several PE's. This then
requires trading in concurrency (since multiple PE's are needed to
store a literal) to process the data set.
This operation is easier to implement on an MIMD processor where each
of the PE's has a considerably larger memory than the "typical"
proposed SIMD processor. Implementation ease aside, an MIMD processor
is probably much faster at this game than an SIMD processor. Don't
forget, in parallel processing SPEED IS THE NAME OF THE GAME.
Sal Stolfo
Stolfo@Columbia
------------------------------
Date: Sunday, 17 November 1985 08:00-PST
From: Steven H. Gutfreund <GUTFREUND@umass-cs.csnet>
Subject: Smalltalk vs. Actors
I have found that one should not look too closely at any of the
definitions that Language or System people provide.
I have a friend who when taking his SYSTEM qualifier, was asked what
was the definition of a PROCESS. For his own amusement (and because he
is a very sharp system person) he proceeded to tell the qual committee
(it was an oral qual) that no such thing exists in reality.
Most people would say that a process is an independent thread of code
with its own state. But he argued that this was so close to the idea
of a co-routine, or to a subroutine that maintains its state between
calls, that one can blur the lines and say that there really is not
clear distinct definition of what a process or task is.
BTW: the technique worked, he amused the committee, kept their minds
reeling and passed the quals, but then, they knew he knew his stuff.
- steve
------------------------------
Date: Saturday, 16 November 1985 22:07-PST
From: coraki!pratt at su-navajo.arpa (Vaughan Pratt)
Subject: Data Abstractions (*very* late response)
(Sorry for the late response - things have been hectic of late.)
Yes, I have developed and am using abstractions specialized for
parallel computing. The central data abstraction is the partially
ordered multiset (pomset), or partial string as some European authors
call it. Here's the idea.
First consider the 5-symbol string LEVEL. This may be considered to
be a 5 element multiset {E,E,L,L,V} together with a linear (total) order
putting the 5 elements in the order L-E-V-E-L.
Now relax the requirement that the order be total. For example we may
choose to make one of the E's independent of V and the other E. This
gives us (reading left to right)
E---V
/ \
L- -L
\ /
-E-
Terminology: in this *pomset* there are 5 *events* and 3 *actions* L,E,V.
Application: let the actions model any of:
states
state transitions
messages
programs
and let the events model instances of those actions (e.g. an instance
of a program is a job). Then a pomset models a *computation* (or *trace*,
or *behavior*) of a system.
The role of the partial order is to specify *necessary temporal
precedence*.
Here's one nice application of this concept. Suppose we want to model
a communication channel. Consider the four events T0, T1, R0, R1
corresponding to transmitting a 0, transmitting a 1, receiving a 0, and
receiving a 1. Suppose the 0 is transmitted before the 1, and the
channel is order-preserving. Clearly we want the order
T0---R0
| |
T1---R1
Where do we get it? Here's an easy way. Start with two strings 01 and
TR, corresponding respectively to a sequence of messages (0 followed by
1) and a sequence of transactions (transmission followed by receipt).
Form the *direct product* of these two strings, viewed as 2-element
partially ordered structures. This is an algebraic construction
yielding a structure whose elements form the Cartesian product of the
elements of its arguments, and which orders (u,v)<=(u',v') just when
u<=u' and v<=v'. A little thought shows that the above desired square
is exactly what you get when you form the direct product of 01 with TR.
Now this square is *not* a string, even though it was formed as the
(direct) product of two strings. Yet it is just what we wanted. The
situation is a little like that with complex numbers. You take the
square root of a negative real and suddenly you're outside the domain
of real numbers.
How does all this relate to concurrency? Well, it gives a trivial
definition for two events to be concurrent, namely when they are
incomparable. Thus strings model purely sequential computation, whereas
other pomsets allow for concurrency.
Rather than get into more technical detail on this model (a bottomless
pit relative to the scope of this message), let me just point to some
papers on the subject.
Gischer, J., Partial Orders and the Axiomatic Theory of
Shuffle, Ph.D. Thesis, Computer Science Dept., Stanford University,
Dec. 1984.
(contains many results about equational theories of pomsets
under various combinations of axioms. Of interest to people
interested in logics of concurrency.)
Mazurkiewicz, Traces, Histories, Graphs: Instances of a Process
Monoid, Proc. Conf. on Mathematical Foundations of Computer Science,
Springer-Verlag Lecture Notes in Computer Science LNCS 176, 1984.
(how several pomset-like models can be viewed as algebras
with one binary associative operation)
Pratt, V.R., The Pomset Model of Parallel Processes: Unifying
the Temporal and the Spatial, Proc. CMU/SERC Workshop on Analysis
of Concurrency, Springer-Verlag Lecture Notes in Computer Science
LNCS 196, Pittsburgh, 1984.
(older paper of mine, good mainly for background)
Pratt, V.R., Some Constructions for Order-Theoretic Models
of Concurrency, Proc. Conf. on Logics of Programs, Springer-Verlag
Lecture Notes in Computer Science LNCS 193, Brooklyn, 1985.
(introduces orthocurrence, cleans up the utilization concept)
(Recently revised version: Modelling Concurrency with Partial
Orders, much more readable, I like it a lot, contact me for a copy.)
Winskel, G., Events in Computation, Ph.D. Thesis, CST-10-80,
Dept. of Computer Science, University of Edinburgh, 1980.
(a heavily algebraic treatment of Petri Nets using a
pomset-like model)
Winskel, G., A New Definition of Morphism on Petri Nets, Proc.
CMU/SERC Workshop on Analysis of Concurrency, Springer-Verlag Lecture
Notes in Computer Science LNCS 196, Pittsburgh, 1984.
(gives one solution to the problem of what is a reasonable
category of Petri nets)
Winskel, G., Categories of Models for Concurrency, Technical Report
no. 58, University of Cambridge, England, undated (rec'd Dec. 1984).
(use of adjunctions between categories to capture
"isomorphisms" between various models of concurrencies)
------------------------------
Date: Tue 12 Nov 85 12:45:02-EST
From: Brian C. Williams <WILLIAMS%MIT-OZ at MIT-MC.ARPA>
To: AIList
Re: Seminar - Multilisp (MIT)
[Forwarded by Steven A. Swernofsky <SASW at MIT-MC.ARPA>]
Thursday , October 14 4:00pm Room: NE43- 8th floor Playroom
The Artificial Intelligence Lab
Revolving Seminar Series
"Multilisp: A Language for Parallel Symbolic Computing"
Burt Halstead
MIT, LCS
Multilisp is an extension of Scheme with additional operators and
additional semantics for parallel execution. These have been added
without removing side effects from the language. The principal
parallelism construct in Multilisp is the "future," which exhibits
some features of both eager and lazy evaluation. Current work focuses
on making Multilisp a more humane programming environment, and on
expanding the power of Multilisp to express task scheduling policies.
A skeletal Multilisp has been implemented, and has been run on the
shared-memory Concert multiprocessor, using as many as eight
processors, as well as on a BBN Butterfly machine with as many as 128
processors. The implementation uses interesting techniques for task
scheduling and garbage collection. The task scheduler helps control
excessive resource utilization by means of an unfair scheduling
policy; the garbage collector uses a multiprocessor algorithm modeled
after the incremental garbage collector of Baker.
The talk will describe Multilisp, discuss the areas of current
activity, and indicate the future direction of the project.
------------------------------
End of PARSYM Digest
********************
∂19-Nov-85 0852 cheriton@su-pescadero.ARPA Re: another paper
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 08:51:27 PST
Received: from su-pescadero.arpa by su-aimvax.arpa with Sendmail; Mon, 18 Nov 85 22:28:31 pst
Received: by su-pescadero.arpa with Sendmail; Mon, 18 Nov 85 22:28:26 pst
Date: Mon, 18 Nov 85 22:28:26 pst
From: David Cheriton <cheriton@su-pescadero.ARPA>
Subject: Re: another paper
To: ark@SALLY.UTEXAS.EDU, nail@diablo, ullman@diablo
How about a real oddity. Surnames with 4 consonants occurring in consecutive
alphabetical ordering (except for duplicates) with the consonants consecutive
except for one vowel!
∂19-Nov-85 0856 @SU-CSLI.ARPA:CLT@SU-AI.ARPA PALMS
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 08:53:45 PST
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 18 Nov 85 16:09:59-PST
Date: 18 Nov 85 1439 PST
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: PALMS
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
PAcific Logic MeetingS
The first of three scheduled for this year will meet at CalTech on
Saturday, Dec. 7. The speakers will be Harvey Friedman, Alain
Louveau, Tony Martin, and Robert Solovay. For more information
contact Matt Foreman, (818) 792-4677.
∂19-Nov-85 0925 RICHARDSON@SU-SCORE.ARPA Tuesday CSD Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 09:24:55 PST
Date: Tue 19 Nov 85 09:10:34-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Tuesday CSD Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12160523482.11.RICHARDSON@SU-SCORE.ARPA>
Just a reminder that there will NOT be a lunch today.
-------
∂19-Nov-85 0938 ullman@su-aimvax.arpa meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 09:38:21 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 19 Nov 85 09:32:04 pst
Date: Tue, 19 Nov 85 09:32:04 pst
From: Jeff Ullman <ullman@diablo>
Subject: meeting
To: nail@diablo
TOmorrow, Kathy is going to fill us in on the interface for
capture rules. I'd like then to start writing some capture
rules in Prolog and also get going on the ICODE->Prolog
translator. Volunteers?
The meeting starts at 11AM in 301.
---Jeff
∂19-Nov-85 0939 LIBRARY@SU-SCORE.ARPA Socrates: Additional Terminal In Math/CS Library
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 09:39:30 PST
Date: Tue 19 Nov 85 09:37:47-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: Additional Terminal In Math/CS Library
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12160528437.33.LIBRARY@SU-SCORE.ARPA>
We now have two public access terminals in the Math/CS Library for searching
Socrates. These terminals also access the technical reports file in
Socrates which is now the only up-to-date index to this material as it
is added to our collection.
Harry Llull
-------
∂19-Nov-85 0944 NILSSON@SU-SCORE.ARPA Visiting Professorship
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 09:44:31 PST
Date: Tue 19 Nov 85 09:41:01-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Visiting Professorship
To: ac@SU-SCORE.ARPA
Message-ID: <12160529023.22.NILSSON@SU-SCORE.ARPA>
John McCarthy has suggested that we institute a regular "visiting
professorship" every year. This will complement our "visiting
industrial professorship." The new visiting professor would ordinarily
be someone who is a professor at some other institution.
It seems to me that this is a good idea for CSD because it would
allow us to benefit from new ideas (perhaps in areas that we are not
covering thoroughly) and it would also allow us to get acquainted with
people who might ultimately want to move to Stanford. The "visiting
professorship" would not replace other visitors that our faculty from
time-to-time invite and support out of their own research funds. Betty
Scott and I will look into funding matters on this, but I wanted first
to assure myself that there are no reasons why this isn't a good idea.
(I can't imagine any such reasons.) May I presume that hearing no
objections to the contrary we could go ahead with this--providing
we can find the money? -Nils
-------
∂19-Nov-85 0945 NEUMANN@SRI-CSL.ARPA RISKS-1.23
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 09:45:04 PST
Date: Tue 19 Nov 85 07:59:48-PST
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSL.ARPA>
Subject: RISKS-1.23
Sender: NEUMANN@SRI-CSL.ARPA
To: RISKS-LIST@SRI-CSL.ARPA
RISKS-LIST: RISKS-FORUM Digest Tuesday, 19 Nov 1985 Volume 1 : Issue 23
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Expecting the unexpected (Peter G. Neumann)
Safety Group Activities in the U.S. (Nancy Leveson)
Automobile computer control systems susceptible to interference (Bennett Smith)
Irresponsible computer "game"; BBS Legislation (Ted Shapin)
SDI Debate at MIT (John L. Mills)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions should
be relevant to the topic, technically sound, objective, in good taste, and
coherent. Others will be rejected. Diversity of viewpoints is welcome.
Please try to avoid repetition of earlier discussions.
Sorry for the hiatus. Circumstances were beyond my control. Thanks to
Frieder von Henke for keeping it from being longer. PGN
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Mon 18 Nov 85 12:57:03-PST
From: Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Subject: Expecting the unexpected
To: RISKS@SRI-CSL.ARPA
We have been talking about risks to the public in the use of computer
systems in this forum since 1 August, and trying to keep the discussions
mostly technical -- but not political or polemical. On the other hand, I
have noted on various occasions that it is sometimes hard to exclude
nontechnical arguments. This message may initially seem off the mark, but I
think it has some subliminal relevance that might help put into perspective
the importance of the underlying assumptions that we make and the need to
anticipate essentially all possible unusual circumstances.
On 13 October 1985, in Florence, Italy, at about 10:05 PM, European Standard
Time, my apparently very healthy 19-year-old son Chris -- never having had a
medical problem in his life -- suddenly had his heart stop and died within
moments. Resuscitation attempts failed. The autopsy found no discernible
apparent cause of death. A neurophysiologist friend who joined me in
Florence suggested ventricular fibrillation as the most likely actual cause.
The heart muscles receive signals from distributed sources via independent
paths, and normally all of the signals arrive sufficiently synchronously to
trigger heart contraction. Under fibrillation, the signals arrive
incoherently, and cannot be integrated sufficiently to trigger contraction.
So, why do I mention this in a RISKS Forum? Well, even in an apparently
completely healthy person there exists some risk of spontaneous malfunction.
It seems to me that in making arguments about how hardware and software will
operate correctly or will continue to operate correctly if they once did, we
make all sorts of implicit underlying assumptions that may be true most of
the time, but that may indeed break down -- particularly in times of stress.
The nastiest problems of all seem to involve unanticipated conditions in
timing and sequencing, in both synchronous and ansynchronous systems, and
particularly in distributed systems. We have seen various problems in the
past -- the ARPANET collapse (due to an accidentally propagated virus, after
years of successful operation) and the first shuttle launch immediately come
to mind as specific well-documented examples. In some cases there is also
signal inference -- as in the pacemaker problems (see Nancy Leveson's
message in RISKS-1.22). I think that in our lives as in computer systems,
we tend to make unjustified or oversimplified assumptions. In life, this
makes it possible for us to go on living without inordinate worrying.
However, in computer systems, greater concern is often warranted. So, my
point in introducing this message into the RISKS Forum is to urge us to try
to make our assumptions both more explicit and more realistic. Basing a
system design on assumptions that are almost but not quite always true may
seem like a close approximation, but may imply the presence of enormous
unanticipated risks. In systems such as those involved in Strategic
Defense, for example, every one of the potentially critical assumptions must
be sufficiently correct.
Peter G. Neumann (back again on the net)
------------------------------
Date: 09 Nov 85 13:04:51 PST (Sat)
From: Nancy Leveson <nancy@ICSD.UCI.EDU>
To: risks@sri-csl.arpa
Subject: Safety Group Activities in the U.S.
Udo wrote about the EWICS TC7 in a previous RISKS forum and said that
such a group died through lack of interest in the U.S. Actually, there
is a similar group which has been active in the U.S. for about three
years. It is called the Software System Safety Working Group and was
started by the Air Force although it is now a tri-service group. Although
sponsored by the DoD, it is not limited to military applications and has
participants from other branches of the government and industry. The latest
meeting was held in conjunction with a conference on computers in medicine.
Meetings are held approximately twice a year and usually have from 50-200
participants. One of the products of the group is a Software Safety Handbook
which is meant to accompany the recent MIL-STD-882b (System Safety) update.
The main purpose of the group has been to meet and discuss new techniques,
share experiences, exchange ideas, etc. There is tentatively a meeting
planned for January in Washington D.C. Anybody interested in the group should
contact me (nancy@uci.edu) or Al Friend (friend@nrl-css) who is with the Navy
and is currently chairing the group. A future plan is to have an on-line
safety database which will reside at the SRI NIC.
Other activities in which I have been asked to participate and which might
be of interest to readers of this forum are a conference on safety
which will be held in Washington D.C. next July and a workshop on safety and
security sponsored by the Center for Software Reliability in England next
September. I am also considering organizing a workshop in California on safety
which would be held right before the next International Conference on Software
Engineering in Spring 1987. Anyone interested in more information on any
of these activities can again contact me and I will direct you to the
right people.
Nancy Leveson
University of California, Irvine
------------------------------
Date: Wed, 23 Oct 85 11:14:29 -0100
From: ircam!bks@seismo.CSS.GOV (Bennett Smith)
Message-Id: <8510231014.AA02863@ircam.UUCP>
To: NEUMANN@SRI-CSL.ARPA
Subject: Automobile computer control systems susceptible to interference
By chance I saw an article in an issue of the
"Journal of Environmental Engineers" (published in England, date of
issue about 10 months ago, I believe) about the sensitivity of
a microprocessor-controlled automobile control system to external
electromagnetic radiation. As I recall, a CB transmitter near the car
could, at the right frequency, make the engine slow down or speed up.
Perhaps this article would interest some of your contributors.
Bennett Smith
IRCAM
31, Rue Saint Merri
75004 Paris, France {seismo,philabs,decvax}!mcvax!ircam
------------------------------
Date: Mon 18 Nov 85 11:54:52-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: Irresponsible computer "game"
To: risks@SRI-CSL.ARPA, human-nets@RED.RUTGERS.EDU
Phone: (714)961-3393; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
From a Toys R Us ad in the L.A. Times, 11/17/85:
Activision
HACKER
Makes you feel like you've unlocked someone else's computer system!
For C-64, C-128. $24.97.
[And on the package:]
TEMPTATION
HACKER
To stumble into somebody else's computer system. To be someplace
you're really not supposed to be. And to get the strange feeling
that it really does matter. "LOGON PLEASE" is all you get to
start with. That's it. From there, it's up to you. If you're
clever enough and smart enough, you could discover a world you've
never before experienced on your computer. Very temptimg.
- - -
This "product" is socially irresponsible! It leads young people
to think breaking into unknown systems is OK. The "world" they
discover may be the world of the penal system!
Ted Shapin
------------------------------
Date: Thu 14 Nov 85 10:34:50-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: BBS Legislation
To: human-nets@RED.RUTGERS.EDU, risks@SRI-CSL.ARPA
I have remailed several messages on pending BBS legislation to
INFO-LAW@sri-CSL. One is a draft of a bill by Senator Leahy's aid Podesta
which is a good bill. People interested in preserving open communcation via
BBS's may wish to read these items. Ted Shapin.
------------------------------
From: Moderator <ARMS-D-Request%MIT-MC.ARPA@MIT-XX.ARPA>
Date: 29 Oct 85 09:33-EST
Subject: Arms-Discussion Digest V5 #8 [EXCERPT: SDI Debate]
To: ARMS-D%MIT-MC.ARPA@MIT-XX.ARPA
Reply-To: ARMS-D%MIT-MC.ARPA@MIT-XX.ARPA
EXCERPTED FROM Arms-Discussion Digest Tuesday, October 29, 1985 9:33AM
Volume 5, Issue 8
[There is sufficient NONOVERLAP in our readerships to
warrant reproducing this. Apologies to those who have
read it already. PGN]
Date: Mon, 28 Oct 85 10:58 EST
From: Mills@CISL-SERVICE-MULTICS.ARPA
Subject: SDI Debate
This is a summary of my impressions of the panel discussion/debate
entitile "Star Wars: Can the Computing Requirements be Met?" This
took place on Monday October 21 at MIT. The panelists where Danny
Cohen, David L Parnas, Charles L Seitz, and Joseph Weizenbaum. The
moderator was Michael L Dertouzos.
I was basically disappointed in this panel discussion. I was hoping
to hear a good counter to the the arguments Dr Parnas had put forth
in his papers. Dr Cohen started what looked like an organized attack
on Dr Parnas' "Octet", refering to the series of eight papers Dr
Parnas presented his arguments in. Dr Cohen correctly dismissed the
eighth paper,"Is SDIO An Efficient Way To Fund Worthwhile Research",
as being outside the bounds of the current discussion. Unfortunately
Dr Cohen only further discussed one of the other papers. The other
six where dealt with with some minor hand waving. I have to admit I
don't remember which paper Dr Cohen "went into detail" on. This is
because the detail amounted to a one slide outline of the major six
points of this paper. This slide was up for no more than one minute
with some more hand waving that none of these points were true.
Back to the side claiming the software is not feasable, Dr Weizenbaum
didn't realy add much of anything to Dr Parnas' arguments. He thought
that Dr Parnas had done a wonderful job and there wasn't much he
could add. He gracefully didn't take up much time saying this either.
Dr Parnas basically presented the material in his papers. He added
the new point that even if we build this thing and it "tested OK",
we could never realy trust it and would be forced not to rely on it.
Charles Seitz made no attempt to directly attack Dr Parnas' argument.
He focused his presentation on a simplistic hierarchal structure the
software for SDI could take. Unfortuanately this looked like a highly
centralized form of controlling all the weapons and sensors resulting
in a high degree of complexity and size.
Both Dr Cohen and Seitz hit upon the point that the software for SDI
is not necessarily as large and complex as some people might think.
They claimed that it could be built of smaller fairly independant
parts. To me this appeared contradictory to Dr Seitz's hierarchal
control structure. It did come through that If you had enough
totally independant platforms shotting things down, you stood a good
change of hitting most the targets. It is also clear that you would
need a very high level of overkill to make this work since the other
platforms don't know who else is shotting at what.
Back to Dr Parnas' points, I did get the feeling that there is some
general agreement that there is a limit to the scale and complexity
our software engineering can handle. Dr Parnas furthered this point
by saying large advances in the mathematics of discreet functions
are going to be a major stumbling block in the furthering software
engineering. He doesn't expect these large advances on the grounds
that if you simplify the equations to much you are loosing
information. A discreet function can only represent so many bits.
I may not have this argument exactly right. He also went thru his
standing arguments against AI or automatic programing helping very
much.
[ I think the argument is that we need concise, manipulable
discrete functions modelling software in order to achieve what
other fields of engineering can do with concise, manipulable
continuous functions. However, such concise representations may
not be possible due to information-theoretic constraints on the
number of bits that can be represented by a certain number of
symbols. --MDAY@MIT-XX ]
[I didn't get quite this impression, though I agree with it. Rather, I
thought Parnas was saying that the problem was in the fact that with
software that is fundamentally digital, there is no such thing as a
continuous function, and that therefore the usual engineering
assumption valid in most of the world that small changes in input or
in correctness necessarily mean small changes in output or result
simply isn't valid in the software engineering world. Until it is
possible to analyze software in terms of approximately correct
functions, graceful software degradation (in terms of an approximately
correct program always doing approximately correct things) is not
really possible. -- LIN@MIT-MC]
Both sides came up with a number of interesting and colorful
analogies. The most relavent is the Space Shuttle. Dr Cohen claims
that the Space Shuttle works. This is obviously true in some sense.
However, it was also pointed out that there have been times when the
software on the shuttle has not worked within seconds of launch. It
seems that it would be impractical to ask the Soviets to wait 15
minutes while we reboot the system.
[Indeed, Seitz conceded that under certain circumstances plausible in
the context of a nuclear missile attack, it might be necessary to
re-boot the system. He then proceeed to ignore the consequences of
that; he did not even say that there are ways to eliminate the need
for re-booting. -- LIN@MIT-MC]
In summary it seems that there are very real limits on what our
software engineering can handle reliably. We are actually not that
far from those limits in some of our current efforts. If SDI is to
work its architecture must be dictated by what is doable by the
software. It is unclear that SDI is feasably from a material cost point
of view if the platforms are small and independant enough to be
reliable from the software standpoint.
In closing I would like to say that I don't think either side did a
particularly good job sticking to just the software feasibility
issue. One other interesting thing happened. Dr Parnas claimed to
have asked some person with authority over SDIO whether "No, we can't
do this" was an acceptable answer. He did this for the first time at
this debate because he did not want to say this behind this person's
back. Unfortunately, I don't remember this other person's name, but
he was in the audience. Dr Parnas claims that the answer was, "No is
not an accepatble answer" and challenged the other person to deny
this. The other person promptly stood up and did exactly
that.
[If you mean that it was political, that's certainly true. But
politics is really the determinant of the software specifications at
the top level. That is how it should be, and people who want to
ignore that are ignoring the most important part of the problem.
However, in other instances, the Administration has noted that the SDI
is central to future US defense policy. In addition, it has never
specified what evidence it would consider adequate or sufficient to
turn off the SDI.
-- LIN@MIT-MC]
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂19-Nov-85 1014 DAVIES@SUMEX-AIM.ARPA No meeting tomorrow, November 20
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 10:13:55 PST
Date: Tue, 19 Nov 1985 10:14 PST
Message-ID: <DAVIES.12160535030.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: No meeting tomorrow, November 20
cc: Davies@SUMEX-AIM.ARPA
No speaker, no meeting.
A speaker is urgently requested to come forward for next week's
meeting. Any volunteers or suggestions for topics?
-- Byron
∂19-Nov-85 1014 CAROL@SU-CSLI.ARPA Sketch demo
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 10:14:03 PST
Date: Tue 19 Nov 85 10:01:10-PST
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: Sketch demo
To: Folks@SU-CSLI.ARPA, Bboard@SU-CSLI.ARPA
*********************************************************************
**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DL
19 Nov 85
**REMINDER**
Richard Burton of Xerox Parc will demonstrate SKETCH, and entertain
questions (and you).
WHEN: 4 p.m.
Tues. 19 Nov. (Today)
WHERE: Trailer F
Contact me if you need the document, a quick introductory lesson,
or if you have any questions. There is a brief version of the
documentation on {CSLI}<DANDELION.DOC>SKETCH, and in the
yellow binders.
-Carol (321-2136, Ventura 28)
ION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION*
*********************************************************************
-------
∂19-Nov-85 1013 LIBRARY@SU-SCORE.ARPA Math/CS Library: New Books--CS
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 10:13:10 PST
Date: Tue 19 Nov 85 09:51:21-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library: New Books--CS
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12160530905.33.LIBRARY@SU-SCORE.ARPA>
Nested Transactions: An Approach To Reliable Distributed Computing.
Research Reports and Notes. Information Systems Series. MIT Press.
by J. Eliot B. Moss. QA76.9.D5M67 1985.
The International Workshop On Language Generation. July 8-10, 1984.
CSLI. (8512399)
Prolog For Programmers. APIC Studies In Data Processing. No. 24. by
Feliks Kluzniak and Stanislaw Szpakowicz. QA76.73.P76K58 1985.
An Artificial Intelligence Approach To VLSI Design. by Thaddeus Kowalski.
Kluwer Academic Pub. TK7874.K675 1985.
Macintosh Revealed. Programming With the Toolbox. Volume twe. by Stephen
Chernicoff. QA76.8.M3C48 1985 V.2.
Current Perspectives In Health Computing. Birmingham University. March
1984. ed by Barbara Kostrewski. British Computer Society. R858.A2C87 1984.
H. Llull
-------
∂19-Nov-85 1140 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar in Logic and Foundations
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 11:40:01 PST
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 19 Nov 85 11:32:37-PST
Date: 19 Nov 85 1125 PST
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: Seminar in Logic and Foundations
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
Speaker: Ian Mason, Philosophy Dept., Stanford
Title: "Proving properties of destructive LISP programs"
Time: Friday Nov. 22, 1985, 12:00-1:00
Place: Math. Faculty Lounge, Room 383-N
S. Feferman
∂19-Nov-85 1145 JF@SU-SUSHI.ARPA p.s. on BATS 11/22/85
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 11:45:49 PST
Date: Tue 19 Nov 85 11:05:57-PST
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: p.s. on BATS 11/22/85
To: aflb.su@SU-SUSHI.ARPA
Message-ID: <12160544486.29.JF@SU-SUSHI.ARPA>
If you want to read the abstracts before deciding, look at
SUSHI:<JF>bats.abstracts
Joan
-------
∂19-Nov-85 1146 JF@SU-SUSHI.ARPA bats headcount
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 11:46:53 PST
Date: Tue 19 Nov 85 11:04:15-PST
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: bats headcount
To: aflb.su@SU-SUSHI.ARPA
Message-ID: <12160544177.29.JF@SU-SUSHI.ARPA>
Is there anyone who plans to attend BATS at DEC this Friday (Nov. 22) who
has not told me? If so, please tell me.
Joan (jf@sushi)
-------
∂19-Nov-85 1243 @SU-CSLI.ARPA:CLT@SU-AI.ARPA course description
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 12:41:24 PST
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 19 Nov 85 12:30:05-PST
Date: 19 Nov 85 1218 PST
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: course description
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA, su-bboards@SU-AI.ARPA
Course description for CS350 (MTC) Winter 1986:
Programming and proving with functional and control abstractions.
Carolyn Talcott
This course combines ideas from semantics of programming languages,
mathematical theory of computation, and program transformations to develop
a semantic foundation for symbolic (Lisp-type) computation. The goals
are: to develop a context in which both intensional and extensinal
aspects of computation can be treated; to provide mathematical tools for
obtaining a better understanding of current practice in symbolic
computation and for representing and proving properties of programs; and
to provide operations on programs with meanings to transform and meanings
to preserve.
The main idea is to treat computation as a process of generating
computation structures such as trees and sequences and to treat more
abstract interpretations of programs as derived notions. The language for
describing computations is that of the lambda calculus extended by
conditional, sequence formation, and context noting primitives.
Additional mathematical tools for reasoning about computation are provided
by a class of approximation and equivalence relations on programs. These
relations are a means forgetting selected details of computations while
preserving evaluation and application relations. There is a maximum
approximation and a maximum equivalence. These maximum relations are
extensional. The recursion operator (Y-combinator analog) computes the
least fixed point with respect to the maximum approximation.
Use of the mathematical tools developed will be illustrated by a variety
of applications. The applications include: proving properties of
programs that use streams, escape mechanisms and co-routines; a
correspondence between streams and co-routines; the use of functionals to
construct and prove properties of programs; program transformations
involving introduction of function and control abstractions; a general
method for converting intensional properties of programs into extensional
properties of ``derived'' programs; and using derived programs to analyze
the effects of program transformations.
Much of the material will be based on a model of computation developed by
Talcott. As background, work in semantics and theory of computation will
be reviewed including work of McCarthy, Landin, Morris, and Wegner. Work
based on alternate semantic models will also be discussed, including work
of Scott, Plotkin, Mosses, and Moschovakis.
Suggested prerequisites: CS306 or equivalent background in logic and Lisp
∂19-Nov-85 1315 EMMA@SU-CSLI.ARPA Newsletter
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 13:15:34 PST
Date: Tue 19 Nov 85 13:05:45-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter
To: folks@SU-CSLI.ARPA
Tel: 497-3479
There will be no newsletter next week because of the Thanksgiving
Holiday. I will be including in this week's newsletter announcements
of all events that occur before Friday, December 6, i.e., two weeks from
this Friday.
Please send the necessary information before noon, tomorrow (Wednesday).
Many thanks,
Emma
-------
∂19-Nov-85 1337 ACUFF@SUMEX-AIM.ARPA Explorer Hardware Watch
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 13:37:21 PST
Date: Tue 19 Nov 85 13:04:02-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Explorer Hardware Watch
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12160565981.31.ACUFF@SUMEX-AIM.ARPA>
If you see either of the following two problems, I'd appreciate it if you'd
let me know so that the associated hardware problem can be addressed:
1. "Burbling" wherein the machine acts like a cat is walking on the keyboard.
Powering the console on and off a few times will usually clear thi
condition, but let me know if it happens.
2. Repeating the last character typed even though no key is down. Typing
another character (anything) will clear this, but, again, let me know.
Thanks,
-- Rich
-------
∂19-Nov-85 1618 RICHARDSON@SU-SCORE.ARPA Faculty Accomplishments
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 16:18:11 PST
Date: Tue 19 Nov 85 16:17:49-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Faculty Accomplishments
To: ac@SU-SCORE.ARPA
Message-ID: <12160601258.31.RICHARDSON@SU-SCORE.ARPA>
This year we will be reporting our "faculty accomplishments" through the
School of Engineering instead of through Humanities and Sciences. SOE has
a stanford form for "faculty accomplishments" which is attached to this
net message. (You will also receive a hard copy through ID mail.)
Please return your completed forms to me either by e-mail or hard copy by
December 2 for forwarding to SOE.
Thanks,
Anne
--------------------------------------------------------------------------
Stanford University
School of Engineering
Annual Faculty Report for Academic Year 1984-85
November, 1985
It is time again for a Faculty Report. This office finds it very useful to
have the information outlined below, and I appreciate you taking time to fill
out the form carefully. I realize that this represents only a summary
of your contributions to the School and misses completely your goodwill
and spirit which are equally important to our mission.
Please give this completed form to your departmental secretary by
December 2, 1985. Thanks for your help with this chore and
for your contributions to the School and the University.
Cordially,
Jim Gibbons,
Dean
(Please note: Information requested pertains to the period 9/1/84 to
8/31/85 only.)
NAME←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Last, First, Middle
ACADEMIC RANK←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
DEPARTMENT←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Publications: (Please indicate nature of work, such as books,
monographs, journals, technical reports, etc., giving title, date, pages and
publisher or issuing agency. Include papers submitted for publication and
designate as such.)
Teaching: (Please indicate by quarter, course title, number of units and
enrollment. Also include course or curriculum development, computer education
software tutorials, specially prepared television presentations or other
relevant work.)
Advising:
Number of freshman advisees
Number of undergraduate advisees
Number of graduate advisees
Supervision of Ph.D. Candidates:
Number of students for which you
are principal dissertation advisor.
Number of students for which you
are on reading committee.
Research Projects:
Project title and Names of Principal Approx. annual dollar
Funding Source and co-Principal value of project for
Investigators, which you are
if any responsible.
University Service Other Than Teaching and Research: (Include
administrative duties and committee work.)
Professional Activities Outside the University: (Include offices in
professional organizations, services to government agencies or industry,
editorship of journals, invited presentations, and outside adminstrative or
public service.)
Honors and Awards:
Describe below any activities or make any comments that do not fit under
previous categories.
-------
-------
∂19-Nov-85 2039 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #36
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 20:32:30 PST
Date: 19 Nov 85 2017-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #36
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 20 Nov 1985 Volume 1 : Issue 36
Today's Topics:
SIMD vs MIMD (4 messages)
Connectionist Summer School
----------------------------------------------------------------------
Date: Monday, 18 November 1985 06:36-PST
From: Seth Steinberg <sas at BBN-VAX.ARPA>
Subject: PARSYM Digest V1 #34
I have just read Alan Bawden's and Phil Agre's paper in which they
explore the programming of the Connections machine by implementing a
Scheme interpreter for it. Since this is probably one of the hairiest
Connections Machine (SIMD) programs ever written it gives one a good
idea of what can be programmed on this type of architecture.
Suppose we want to run a program which contains a conditional on a
SIMD machine. First we tell all the processors to evaluate the
predicate, which is rather straightforward. All processors do the
same test and then they set some condition code. Then we send out the
"then clause" with the instructions suitably modified so that they are
only performed if the condition code is set, then we send out the
"else clause" with the instructions modified so that they are only
performed if the condition code is not set. In other words executing
a conditional on a SIMD machine we take time P+T+E
(predicate+then+else) as opposed to max(P+T,P+E). As Danny Hillis
points out in his book (The Connection Machine), you tend to have to
accept the worst case rather than the typical case.
I recently read a paper by Alan Bawden and Phil Agre in which they
implemented a Scheme interpreter for the Connection Machine. A Scheme
program is decomposed into abstract data objects (e.g. assignment
objects which know about the target and the expression, conditional
objects which know about the predicate, then and else clauses and so
on). They implement this by using one processor to represent one data
object by placing it in a suitable state so that it only executes the
instructions for implementing that type of object.
It's kind of like those Avalon Hill war games where the enemy gets to
advance scouts, advance infantry, now you get to advance scouts and
infantry, then they shoot at each other, now the enemy advances his
tanks, then you advance your tanks, they shoot at each other and at
the infantry and the scouts. Now the medics remove the wounded and
you tot up the damage done and you're ready for the next turn. Some
Avalon Hill games were real good SIMD training.
To interpret Scheme the master controller has to send out all the
instructions for all of the conditional type objects (object and
processor will be used interchangeably here). This means ALL the
instructions including those for each case (handling both the then and
else cases). It also has to send out all the instructions for all the
assignment type objects, and the sequences, and the procedure
applications, and the closure creaters and so on. (I haven't even
mentioned the code for +, -, eq?, null?). In other words, the entire
Scheme interpreter (just about) has to be sent down the instruction
wires every so often.
I imagine the folks at MIT actually considered running Scheme this way
especially if they considered the projected enrollment in 6.001 in the
year 1990, but they decided just to get more detached work stations.
In any event, Scheme will not run particularly efficiently on a
Connection Machine because it has too many different types of objects
in it.
Programs which run efficiently on a CM are those in which all the
objects are of the same type. As the theoretical physicists tell us,
it is not all that dificult to make two different typed objects seem
to be of the same type modulo some marker (spontaneous symmetry
breaking) but a SIMD machine must still check for those markers at
some time. If we argue that all Motorola 68000 instructions are the
same except for their opcodes we can indeed emulate a MIMD machine on
a SIMD machine but we still have to send out the emulation sequence
for every instruction each emulated cycle.
In general, SIMD machines execute Fortran and APL very well. (The
latter language is full of nifty symmetry hacks). I am exaggerating
for effect but it is probably safe to say that any algorithm which
actually looks elegant when written out in Fortran can probably be
made to run efficiently on a SIMD machine. Any APL one liner (and
there were a lot of graph theory one liners) can be made to run
efficiently as well. This is a LOT of code, and more importantly,
this is a lot of code FULL of repeated iterations - it is that 10%
which eats up 90% of the typical conventional processor.
There are many algorithms which don't quite fall into this basket
though. It is hard to do symbolic integration, make legal decisions,
parse a sentence, compile COMMON LISP, run a numerical backsolver, or
perform any operation which has to deal with lots of different kinds
of objects and lots of special cases. UNIX, like any other piece of
system code, is FULL of special cases.
My feeling is that SIMD machines have their place but that they are
still poorly understood. Perhaps they should be partitionable with
different partitions receiving different instruction streams (NIMD)
which would make BIBOP Scheme quite practical. As far as software
goes we are back at core memory and Fortran I.
Speaking for Myself,
Seth Steinberg
P.S. I realize that some of my opinions in here could be quite
offensive. No offense has been intended, I have been trying to
understand the SIMD world and my understanding has been subject to
massive and sudden mood swings.
------------------------------
Date: Monday, 18 November 1985 19:18-PST
From: gary at THINK.COM
Subject: SIMD vs MIMD
In reply to Sal's letter:
>Think of the different tests and branches that would need to be issued
>from the control processor to the SIMD processor to account for every
>possible type of first order term encountered.
The tests and branches that a SIMD program would have to contain are,
syntactically, exactly the same as those in a program running on a
processor in a MIMD machine. It is just as easy to write the SIMD
program as to write an ordinary serial program. The difference comes at
run time: the SIMD host has to run through the code for all possible
outcomes of conditional branches, but a serial computer, or the
processors of a MIMD computer, can just skip over sections of code when
a condition evaluates to false. However, this process is transparent to
the programmer.
>Implementation ease aside, an MIMD processor is probably much faster at
>this game than an SIMD processor. Don't forget, in parallel processing
>SPEED IS THE NAME OF THE GAME.
Of course a MIMD computer will be faster than a SIMD computer at any
task, when they have an equivalent number of processors. The comparison
that should be made is between a MIMD and a SIMD computer implemented on
equivalent amounts of silicon. Because SIMD computers do not need to
devote silicon to control and program store at each processor, a SIMD
computer can have more processors than a MIMD computer for any given
amount of silicon. For most "real problems" (as defined by Brad's
original letter) this more than compensates for the need to turn off
some of the processors when a conditionalized statement is executed.
------------------------------
Date: Tuesday, 19 November 1985 10:38-PST
From: eldridge at EDN-VAX.ARPA (Charles Eldridge)
Subject: SIMD versus MIMD
Expert systems should be an application area in which MIMD
has advantages over SIMD. That is, a number of searches must
be performed in order to competitively evaluate chains of
reasoning. SIMD would require that these searches be carbon
copies of one another, while MIMD would allow them to pursue
differing branches, having different lengths and evaluating
different (perhaps) mathematical functions along the way.
Have you seen "A Qualitative Assessment of Parallelism in
Expert Systems," by R. J. Douglass in IEEE Software, May 1985,
and
"Providing Architectural Support for Expert Systems," by
P. C. J. Graham, ACM SIGARCH Computer Architecture News,
December, 1984?
--Charles Eldridge
------------------------------
Date: Tuesday, 19 November 1985 09:02-PST
From: Guy Steele <gls at THINK-AQUINAS.ARPA>
Subject: PARSYM Digest V1 #35
This comment is in response to the interesting and provocative remarks
of Sal Stolfo about SIMD versus MIMD.
Perhaps speed is the name of the game, but I would suggest that speed
of solving a problem is the name of the game, not speed of individual
processors.
I think that SIMD appears to many people compare unfavorably to MIMD
because it is tempting, in the mind's eye, to picture a single
processor, whether SIMD or MIMD, as being of about the same size. I
think we tend to mentally compare a 1000-processor SIMD machine with a
1000-processor MIMD machine. In such a comparison the MIMD machine
probably does come out ahead in speed and flexibility (though perhaps
not in ease of programming, yet again perhaps so).
But if one compares the two strategies by insisting that each systems
consist of about the same amount of hardware (or have about the same
dollar cost), then the SIMD machine might come out with (a) more
processors and/or (b) greater data bandwidth. It might have more
processors because instruction-fetching and decoding circuitry can be
shared, and so the part of each processor that must be replicated can
be smaller. It might have greater data bandwidth because a much
smaller proportion of memory accesses go toward instruction fetching.
These two effects may compensate for inefficiencies introduced by the
time-slicing of SIMD processors in emulation of MIMD programming mode.
As for the amount of memory per processor, I think that any computer
tends to have a certain fraction of hardware devoted to memory and the
rest to processor. (Whether this is essential (I doubt it), the
result of tradition, or the result of economic pressures is unclear to
me.) If a SIMD and a MIMD system have the same amount of hardware,
and each devotes the same fraction of hardware to memory, and if
conjecture (a) above holds (the SIMD machine has more processors),
then naturally there will be less memory per processor. But the total
amount of memory is the same, and if one insists on assigning one
problem element per processor, then the SIMD machine can handle
problems with more elements, even though each one must be smaller.
Alternatively, one can afford to assign multiple processors to each
problem element; I don't call this "trading in concurrency" if this
allows handling a problem of the same size as the equivalent (in
hardware size) MIMD machine.
I certainly agree that performing unification on many expressions in
parallel is much easier to think about in MIMD terms, and a MIMD
programming interface is a useful one. I do not think that this
necessarily implies that the underlying software and hardware should
be understood or constructed in MIMD terms at all levels. In any case
we should be careful to define exactly and fairly what is being
compared. A Cray will almost always beat out a PCJr--but at what
cost? As another example, I don't think it is fair to say that
NON-VON is better than a Connection Machine because NON-VON has 8-bit
processors and CM has 1-bit processors. Nor is it fair to say that CM
is better for having 64K processors to NON-VON's 8K processors.
(Indeed, I think these two systems are roughly comparable at an
architectural level, in that on each "cycle", whatever that means,
each machine can fetch and process 64K bits. I am speaking here in
ignorance of clock speeds. Differences in instruction sets will of
course result in differing performance on specific applications.) One
can have a very good discussion about whether NON-VON's multiple
controllers, giving it more of a MIMD flavor at that level than CM,
constitute an advantage for certain applications.
--Guy
------------------------------
Date: Monday, 18 November 1985 18:36-PST
From: Brewster Kahle <KAHLE at THINK-AQUINAS.ARPA>
Subject: A good use of MIMD
MIMD machines are appropriate (at least) when the processors are
physically far from each other, such as process control in a factory.
This may seem like a trivial point, but it is enough of an issue to
keep some people working on how to control them.
-brewster
------------------------------
Date: Monday, 18 November 1985 20:29-PST
From: Dave.Touretzky at A.CS.CMU.EDU
Subject: summer school
CONNECTIONIST MODELS: A SUMMER SCHOOL
Sponsored by the Sloan Foundation
ORGANIZERS: Geoffrey Hinton (Carnegie-Mellon University)
Terrence Sejnowski (The Johns Hopkins University)
David Touretzky (Carnegie-Mellon University)
DATE: June 20 through 29, 1986
PLACE: Carnegie-Mellon University, Pittsburgh, Pennsylvania
PURPOSE OF THE PROGRAM: The purpose of the summer school is to
familiarize young researchers with current techniques in the area of
connectionist models of intelligence. This includes search
procedures, learning procedures, and methods for representing
knolwedge in massively parallel networks of neuron-like units.
Application areas include vision, speech, associative memory, natural
language and motor control.
FACULTY: There will be six full time Tutors plus several Guest Lecturers.
Tutors: Guest Lecturers:
James Anderson, Brown University Jerome Feldman, U. of Rochester
Dana Ballard, U. of Rochester Christof Koch, MIT
Andrew Barto, U. Mass. Amherst David Rumelhart, UCSD
Geoffrey Hinton, CMU David Touretzky, CMU
James McClelland, CMU others to be announced
Terrence Sejnowski, Johns Hopkins
WHO MAY ATTEND: Participation is limited to graduate students and
recent PhD's who are or will be working on connectionist models.
About 40 students will be accepted. Persons who have already
completed a Ph.D. degree must have done so no earlier than January
1985 to be eligible to attend.
EXPENSES: There is no tuition charge. Funding from the Sloan
Foundation will provide dormitory accommodations and breakfast and
lunch for each attendee, plus reimbursement for a substantial portion
of travel expenses.
HOW TO APPLY: By March 1, 1986, send your curriculum vitae and a copy
of one relevant paper, technical report, or research proposal to: Dr.
David Touretzky, Computer Science Department, Carnegie-Mellon
University, Pittsburgh, PA, 15213. Applicants will be notified of
acceptance by April 15, 1986.
------------------------------
End of PARSYM Digest
********************
∂20-Nov-85 1153 RICE@SUMEX-AIM.ARPA 36xx -> Explorer Status.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 11:53:37 PST
Date: Wed 20 Nov 85 10:40:19-PST
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: 36xx -> Explorer Status.
To: aap@SUMEX-AIM.ARPA
Message-ID: <12160801963.66.RICE@SUMEX-AIM.ARPA>
Progress report on the porting of code to Explorers.
This is the current state of the systems, in which the architectures project
might be interested, that are being ported to the Explorers.
Before you try to load any of these systems you should load up the
compatibility package files. This is done with the following :-
(Load "3602:>Tools>36xx-Explorer")
(Load "3602:>Tools>36xx-Explorer-2")
(Load "3602:>Tools>36xx-Explorer-3")
These fix a fair number of the known bugs and/or incompatibilities, which we
have addressed. They may change from time to time so you would do well to look
in the Tools directory for any changes. Once all of these changes have been
logged properly they will be collapsed into one file so watch out.
As usual any bug reports and/or fixes should be channeled through Mr Acuff so
as to prevent the reinvention of the wheel and unnecessary flamage.
Helios - No work has been done on this yet but it is not critical.
Simple - This appears to work except for the timing patch.
Care - This can be loaded as XCare. All of the subsystems seem to
work but for the timing patch in Simple. Backup (Care)
systems are yet to be made.
To load it do the following :-
(Make-System 'XCare :Noconfirm :Silent :Nowarn)
System-Manager -This seems to work but for a problem with typeout windows.
TI are looking at the problem. Sources will eventually be
moved to Ardvax but not until TI/Mr Acuff can fix the bugs
in the pathname system for Unix machines.
To load it do the following ;-
(Make-System 'System-Manager :Noconfirm :Silent :Nowarn)
L100 - The L100 compiler is fully operational on the Explorers.
You can load it with :-
(Make-System 'L100 :Noconfirm :Silent :Nowarn)
Tina-Language - This is fully operational on the Explorers.
To load this please load the tina system first (see below)
and then do :-
(Make-System 'Tina-Language :Noconfirm :Silent :Nowarn)
Cage-Language - This works as much on the Explorers as it does on the 3600s.
You can load it with :-
(Make-System 'Cage-Language :Noconfirm :Silent :Nowarn)
Tina - This works fully on the Explorers but for a small problem in
the trace/debug menus. This should be fixed soon.
You can load it with :-
(Make-System 'Tina :Noconfirm :Silent :Nowarn)
Czar/Caos - Work has started on porting this. It currently gets most of
the way through its initialisation but is being held up by
what could be a microcode bug. This is being investigated.
Parallel-Tina - This is predicated in Czar so work has not started.
Early next week we expect some new system software and sources. This may
well change things but with luck it will allow us to respond to bugs more
rapidly.
If you have any questions about these systems please see me. If you have any
questions about your machine please see Mr Acuff.
Rice
-------
∂20-Nov-85 1158 PATASHNIK@SU-SUSHI.ARPA Next AFLB
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 11:58:42 PST
Date: Wed 20 Nov 85 06:16:00-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: Next AFLB
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12160753845.12.PATASHNIK@SU-SUSHI.ARPA>
This week's AFLB has turned into a BATS talk on Friday, and next week
is Thanksgiving, so the next AFLB will be in two weeks:
*************************************
5-Dec-85 : John Cannon (University of Sydney)
Finding the order of a permutation group of degree 10,000
(Abstract forthcoming)
***** Time and place: December 5, 12:30 pm in MJ352 (Bldg. 460) ******
-------
∂20-Nov-85 1205 NEUMANN@SRI-CSL.ARPA RISKS-1.24
Received: from SRI-CSL.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 12:04:55 PST
Date: Wed 20 Nov 85 07:57:30-PST
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSL.ARPA>
Subject: RISKS-1.24
Sender: NEUMANN@SRI-CSL.ARPA
To: RISKS-LIST@SRI-CSL.ARPA
RISKS-LIST: RISKS-FORUM Digest Wednesday, 20 Nov 1985 Volume 1 : Issue 24
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Doing Something About Risks in Computer Systems (Brad Davis)
Space Program Software (Jerome Rosenberg)
Susceptibility to interference (John Brewer)
Expecting the unexpected (Herb Lin)
Philip W. Anderson's "Case Against Star Wars" (Pete Kaiser)
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions should
be relevant to the topic, technically sound, objective, in good taste, and
coherent. Others will be rejected. Diversity of viewpoints is welcome.
Please try to avoid repetition of earlier discussions.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Tue, 19 Nov 85 11:05:34 MST
From: b-davis@utah-cs.arpa (Brad Davis)
To: RISKS@sri-csl.arpa
Subject: Doing Something About Risks in Computer Systems
Often the discussion has touched on failure of software and hardware, but
rarely on levels and methods of protection that should be built into these
systems. Is is good to trade cycles for protection? What are the best ways
to recover from failures? Does anyone have real experiance with these
questions?
Brad Davis
[Clearly these are leading questions! We have indeed mentioned many
good techniques of software engineering that help. But there are no
easy answers -- especially in the absence of specific requirements.
But let's see if any of our readers wants to take a crack at this one.
PGN]
------------------------------
Date: Tue, 19 Nov 85 14:46:49 CST
From: jerome@rsch.wisc.edu (Rosenberg Jerome)
To: RISKS@sri-csl
Subject: Space Program Software
We have heard a great deal about the great successes of the space
program but we rarely hear about the difficulties that have to be overcome
with great effort and dedication. I suggest you direct your readers to the
current issue of DATAMATION for an article by Edward Joyce entitled "The
Art of Space Software". Its subtitle tells a far different story than
some hand-waving protagonists of the SDI tell about the Space software.
The subtitle -- The complicated software labyrinth behind the shuttle is
still far from error-free -- tells the story. The article should serve to
alarm those who are quick to discount the sincere critics of the SDI
software problems. jerome @rsch.wisc.edu
------------------------------
Date: Tuesday, 19 Nov 1985 10:21:51-PST
From: brewer%ace.DEC@decwrl.DEC.COM (too busy for bureaucracy -John 5522026)
To: risks@sri-csl.ARPA
Subject: Re: Susceptibility to interference
RE: Bennett Smith's comments of emi-rfi susceptibility in automobile
control applications... cb's are low power, limited frequency devices. As an
Amateur radio operator, one has to be aware of much higher output power, as
well as a much wider bandwidths. Amateur Radio frequency allocations include
segments from 1.8Mhz to Ghz ranges.
As I remember, some of the control modules are also pretty good
emitters of Emi/Rfi hash as well. Typical (legal) output power of a CB is 5
watts or less. A typical ham radio mobile transmitter output power is
100-200 watts.
Something to think about!
-John
------------------------------
Date: Tue, 19 Nov 85 15:10:41 EST
From: Herb Lin <LIN@MIT-MC.ARPA>
Subject: Expecting the unexpected
To: RISKS@SRI-CSL.ARPA
Regarding your comments about spontaneous failure: The Russians have a
saying regarding rifles used on stage in plays: once every decade an
unloaded gun will fire; once every century a rake will fire.
[Perhaps that is what prompted Stravinsky to stage
"The Rake's Progress". PGN]
------------------------------
Date: Wednesday, 2 Oct 1985 21:32:34-PDT
From: kaiser%furilo.DEC@decwrl.ARPA (Pete Kaiser, 225-5441, HLO2-1/N10)
To: RISKS@SRI-CSLA.ARPA
Subject: Philip W. Anderson's "Case Against Star Wars"
[The following message was put aside for evaluation before my absence.
With the reminder that we of course would like to see more informed
pro-SDI contributions in RISKS as well, Anderson's article seems
worth including -- not because it breaks new ground, but because it
represents a position for discussion. PGN]
The article below, by Professor Philip W. Anderson of Princeton University,
appeared in the Princeton Alumni Weekly of September 25, 1985, and is reprinted
here with the author's permission. Professor Anderson won the Nobel Prize for
Physics in 1977, and was awarded the National Medal of Science in 1982.
Although what Professor Anderson has to say is couched partly in specific terms
of Princeton University and the discipline of academic physics, it seems to me
relevant to basic research in general, and to computer science research and the
discipline of computer science in particular. To me, for instance, it seems to
be very personally a social consequence of the military funding of computer
science research that, while I've worked with computers, there have been many
kinds of work which I couldn't conscientiously do because, although they may be
very interesting, they are done essentially only for military purposes and with
military funding.
Finally, Professor Anderson points out that a great deal of sensible thought can
be brought to social issues even by someone who "isn't ... fascinated by the
technical details." Agreed. We must remember that we're not priests.
---Pete
Kaiser%BELKER.DEC@decwrl.arpa
{allegra|decvax|ihnp4|ucbvax}!decwrl!dec-rhea!dec-belker!kaiser
DEC, 77 Reed Road (HLO2-1/N10), Hudson MA 01749 617-568-5441
----------------------------------
The Case Against Star Wars
Philip W. Anderson, Princeton
I am not an expert on strategic weapons. I'm a theoretical physicist who has
been involved in almost all of physics except atomic bombs. I have not done
classified work since 1945, and that was on radar. My total contribution to the
laser -- a major technical component of the Strategic Defense Initiative, which
is better known as Star Wars -- was roughly that when one of the scientists at
Bell Laboratories who originated the things asked me to predict whether a
certain seminal version of it would work if they built it, I said "Well, maybe."
Fortunately, most of the scientific issues that come up in discussing Star Wars
are very simple ones which require neither specialized nor especially technical
-- and therefore classifiable -- knowledge. One needs to know that it costs
everyone about the same amount to put a ton of stuff into a given orbit and that
this is a major portion of the cost of any space system; that signals can't
travel faster than the speed of light; that it takes roughly as much chemical
fuel to burn through a shield with a laser as the shield itself weighs; that
Americans are not measurably smarter than Russians; and a few other simple, home
truths. Given these, almost everyone comes to much the same conclusions.
If you go through the enormously detailed kinds of calculations on specific
configurations which Richard Garwin and his fellow opponents of SDI felt
necessary to convince the stubborn, you leave yourself open to the kind of
errors of factors of 2 or 4 which Martin Muendel '86 found in his widely
publicized junior paper last spring [Princeton Alumni Weekly, May 8] and which
then -- to the lay person -- seem to weaken the whole structure. This is a
particularly tough game because Star Wars advocates do not themselves propose
specific configurations and present specific calculations that can be shot down;
their arguments are given in terms of emotional hopes and glossy presentations.
This is why I think it is good for the argument against SDI to be made by a
mentally lazy, non-expert person like myself who isn't particularly fascinated
by the technical details.
The reasons for not building Star Wars are essentially identical to those which
led both us and the Russians to abandon, for practical purposes, the antibal-
listic missile in 1972 and to sign a treaty restricting ABMs. It is important
to understand that reasoning -- and perhaps it is less emotionally charged than
Star Wars since it is now history and not even controversial history anymore.
Why would anyone feel that a defense against missiles was useless and, in fact,
dangerous and destabilizing?
There are three stages, each more certain than the last: (1) It probably
wouldn't work, even under ideal conditions. (2) It almost certainly wouldn't
work under war conditions. This puts us in the dangerous and unstable situation
of the gunfighter who doesn't know if his gun is loaded. (3) Most certain and
conclusive of all, *each defensive system costs, inescapably, at least 10 times
more than the offensive system it is supposed to shoot down*. Thus it pays the
other side to increase its offensive arsenal until the defender is bankrupt, and
the net result is an *increase* in armaments and a far more dangerous situation,
without any increase in safety.
The offense has, inescapably, enormous advantages: its missiles are sent at
will, in any desired sequence and quantity, with any number of decoys and other
deceptive countermeasures, preprogrammed at leisure to hit their targets; the
defense has to find them, sort them out, get into space at a time not of its own
choosing, and then kill the warheads it finds with nearly perfect accuracy. In
the case of ABM, there were other problems, such as that the explosions were
over the defending side and that the first few explosions probably blacked out
the whole shooting match, but that was sufficient argument against.
As far as almost everyone in and out of the Defense Department was concerned,
until March 1983 this situation was an accepted fact. No technical breakthrough
had or has changed those realities. The change has been purely political and
emotional, and hence now financial. President Reagan's March 1983 speech, as
far as anyone can ascertain, was not preceded by any serious technical review,
but quite the opposite: the most recent and urgent internal study of antimissile
defenses had come out negative on all possible schemes.
Apparently, the President based his speech and his subsequent program on a
collection of rather farfetched suggestions -- farfetched but by no means secret
and previously unknown -- which, to the outside scientific observer, seem to
deserve the oblivion that the last pre-Star Wars study consigned them to. These
schemes amount to a way for the defense to spend more per missile and still let
through a large fraction of the offensive missiles. The defensive hardware that
has to be got up into space still has to have roughly the same mass as the
offense; in many schemes it has to get there faster; and it still has to be much
more sophisticated and therefore vulnerable and delicate. Key components, in
most schemes, have to be left in space indefinitely, inviting the enemy to track
them with space mines, perhaps the most dangerous tripwire mechanism for stating
a war that one can possibly imagine.
Some Star Wars advocates will protest that I do not mention the one idea which
doesn't founder just on the problem of total mass in space. This is the scheme
of exploding hydrogen bombs in space and directing the explosive energy of the
bombs with lasers to kill very many missiles per bomb -- several hundred to
several thousand, if one is to kill an equivalent cost in missiles! If I could
think of any way such a monstrosity could work as opposed to the many ways it
could not work or be frustrated, I would take it more seriously. Apparently
there has been some good and interesting science done on these lasers, but
unfortunately it is classified; no one, however, seems to claim that it helps
much with the technical problem. I cannot, incidentally, see any way to do
meaningful development on such a weapon without exploding H-bombs in space, a
terrible pollution as well as a violation of what treaties we have.
I think the above would represent reasonably well the views on the technical
realities of most trustworthy physicists to whom I have spoken, in or out of
academia and in or out of the Star Wars program. In academic physics depart-
ments, which receive relatively little support from the DOD, a pledge form has
been circulating stating that the signer opposes SDI as unworkable and will not
seek SDI funds; this has had a high percentage of signers everywhere it has been
circulated and its preliminary circulation in Princeton over the summer encoun-
tered only a few holdouts. Those who do not sign feel, primarily, that research
in any guise shouldn't be opposed, while agreeing personally that the systems
proposed are unworkable and destabilizing.
Perhaps it would be worthwhile, therefore, for me to explain why I feel the
large increment of research funds earmarked by President Reagan for SDI is a
very bad thing for the research community, as well as for the country as a
whole. You will note that I said *increment*; every year before Star Wars, we
spent $1 billion in ABM research and development. My main reason is that, on
the whole, Star Wars will represent a further acceleration of three extremely
disturbing trends in the direction of research funding in this country.
First, we are seeing a decrease in basic research relative to mission-oriented,
applied research. The basic research agencies -- National Science Foundation,
Basic Energy Sciences in the DOE, and National Institutes of Health -- have been
maintained at level funding while their missions have been gently skewed toward
applications and engineering by piling more applied responsibilities on them.
At the same time, while the Administration has cut back on development in some
civilian sectors, it has more than compensated by increasing the amount of
applied work for the military.
Second, there is a trend away from scientific administration of federal research
money -- mostly done by the system of "peer review" -- to micromanagement either
by bureaucrats, or, increasingly, by Congress, with all the logrolling possibil-
ities that entails. The three institutions mentioned above, especially NSF and
NIH, operate by subjecting each grant to a jury or other scientists. Like most
democratic procedures, this system is worse than everything except the alterna-
tives; its effect has been reviewed repeatedly and there is no serious doubt
that it works. Military "research," on the other hand, has always operated on
the arbitrary whim of the contracting officers. In the early days after World
War II this administration was a benevolent despotism, but the adjective has
long since lost its meaning. Most of the in-house DOD laboratories have been
rather a scandal in the research community. The dominant motivation in this
system seems to be the standard bureaucratic one of "empire building."
Third, from the point of view of the country as a whole, perhaps the most
dangerous trend is the shift from civilian to military dominance of our federal
research and development spending. Under the Reagan Administration, this has
grown to 72 percent military, up from about 50 percent a decade ago. Everyone
has been told -- and DOD sees to that -- of the great economic benefits of
"spin-off" from military development, but if they exist (and I have never found
an economist who believes in them), they are not evident in our recent economic
performance vis-a-vis Japan and Germany. In fact, in a country like ours with a
serious shortage of trained engineers and scientists, a shortage which would be
crippling if we did not attract great numbers of them from overseas to staff our
universities and research laboratories, the waste of our precious technical
expertise on military hardware is a serious economic debit.
From Princeton's point of view, all of these trends are disturbing. As a top-
flight research university, a heavy percentage of our funding is in individual
support of independently functioning basic scientists, mainly peer-reviewed and
to a large extent from the agencies mentioned above. We have not had to resort
to logrolling political tactics, nor have we had to accept micromanagement, DOD
control of publications, or limitations on citizenship of students to keep our
research funded. SDI control of funding, and in general the shift of research
funding to the military, is a serious danger to the independence of Princeton as
a research university.
Of course, this is a narrow and slightly parochial view, but it is nonetheless
serious. Certainly it is more important that the naive emotional appeal of the
Star Wars concept is being used so blatantly to defuse the country's strong
desire for nuclear disarmament, and to turn this emotional pressure into yet
another excuse for enriching the arms manufacturers and building up a dangerous
and worthless arsenal of nonsensical armaments. To paraphrase Murph Goldber-
ger's testimony on the ABM: Star Wars is "spherically" senseless -- that is,
silly no matter how you look at it.
[End of Philip Anderson's statement, and of Pete Kaiser's Message.]
------------------------------
End of RISKS-FORUM Digest
************************
-------
∂20-Nov-85 1205 LIBRARY@SU-SCORE.ARPA Socrates: Update On Searching Math/CS Technical Reports By Call Numbers (Accession Numbers)
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 12:04:28 PST
Date: Wed 20 Nov 85 11:52:05-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Socrates: Update On Searching Math/CS Technical Reports By Call Numbers (Accession Numbers)
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12160815027.41.LIBRARY@SU-SCORE.ARPA>
You may now search out technical reports by our call number (or accession
number) with or without the leading zeros. Technical report number 009902
may be found by searching Fin C 009902 or Fin C 9902.
Be aware that besides the call number index there is also a Number index
which includes the technical report numbers and not call numbers. Because
this file includes reports from various science libraries, technical report
numbers and call numbers will vary in how they are entered. Computer
Science Technical report numbers will vary with some of them having just
a unique number and others have a unique number preceeded by a year notation
such as 84-201 or 85-609. You need to be very cautious when searching
either the number index or the call number index. If you have any
problems, let me know.
Harry Llull
-------
∂20-Nov-85 1238 YAMARONE@SU-CSLI.ARPA HUNGRY? X-TRA SANDWICHES AVAILABLE
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 12:36:50 PST
Date: Wed 20 Nov 85 12:27:00-PST
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: HUNGRY? X-TRA SANDWICHES AVAILABLE
To: folks@SU-CSLI.ARPA
TWO TURKEY SANDWICHES ON LIGHT RYE WITH THE WORKS ARE AVAILABLE AT
THE FRONT DESK FOR A MERE $2.50 EACH.
COME AND GET IT! FIRST COME, FIRST FED!
THANK YOU, THE VENTURA SANDWICH CORP.
-------
∂20-Nov-85 1407 @SU-SUSHI.ARPA:PAPA@SU-SCORE.ARPA Talk by Victor Klee
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:07:28 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 20 Nov 85 14:02:00-PST
Date: Wed 20 Nov 85 14:01:55-PST
From: C. Papadimitriou <PAPA@SU-SCORE.ARPA>
Subject: Talk by Victor Klee
To: aflb.local@SU-SCORE.ARPA
Message-ID: <12160838663.47.PAPA@SU-SCORE.ARPA>
Victor Klee is giving a Colloquium today on:
``The Complexity of Linear Programming: The d-step Conjecture After 30 Years''
The colloquium is in the Materials Science Auditorium (next to the
Earth Sciences building, room 550?), Thursday Nov. 22 at 4:30.
---CHP
-------
∂20-Nov-85 1502 @SU-SUSHI.ARPA:PAPA@SU-SCORE.ARPA V. Klee's talk
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:58:06 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 20 Nov 85 14:20:30-PST
Date: Wed 20 Nov 85 14:20:23-PST
From: C. Papadimitriou <PAPA@SU-SCORE.ARPA>
Subject: V. Klee's talk
To: aflb.local@SU-SCORE.ARPA
Message-ID: <12160842024.15.PAPA@SU-SCORE.ARPA>
Victor Klee's seminar is TODAY WEDNESDAY, and not tomorrow Thursday.
Sorry for the (multiply) contradictory message...
---Christos.
-------
∂20-Nov-85 1506 YAMARONE@SU-CSLI.ARPA HUNGRY?? TURKEY & AVO AVAILABLE
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 15:04:54 PST
Date: Wed 20 Nov 85 14:53:44-PST
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: HUNGRY?? TURKEY & AVO AVAILABLE
To: FOLKS@SU-CSLI.ARPA
I KNOW THESE SANDWICH MESSAGES ARE STUPID AND A P.I.T.A...BUT
I'M NO WHEEL, SO PARDON ME.
THERE IS HOWEVER A DELICIOUS SANDWICH AVAILABLE TO THE FASTEST
PERSON TO RESPOND.
A SPECIAL TURKEY AND AVOCADO ON SLICED SOURDOUGH WITH EVERYTHING
EXCEPT MUSTARD.....$3.00 ....
COME TO THE FRONT DESK IF YOU'RE INTERESTED....
SORRY FOR THE INTERRUPTION, THE VENTURA SANDWICH CORP.
-------
∂20-Nov-85 1604 @SU-SUSHI.ARPA:SILVERBERG@SU-SCORE.ARPA Talk by Victor Klee
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 16:03:36 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 20 Nov 85 14:21:41-PST
Date: Wed 20 Nov 85 14:21:32-PST
From: Ellen Silverberg <SILVERBERG@SU-SCORE.ARPA>
Subject: Talk by Victor Klee
To: aflb.local@SU-SCORE.ARPA
Message-ID: <12160842234.10.SILVERBERG@SU-SCORE.ARPA>
Victor Klee's talk is today, Wednesday Nov. 20 at 4:30 (in case the previous
message had you confused). The room is 550A Materials Science Engineering.
Ellen
-------
∂20-Nov-85 1814 EMMA@SU-CSLI.ARPA Newsletter November 21, No. 3
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 18:14:43 PST
Date: Wed 20 Nov 85 17:05:29-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter November 21, No. 3
To: friends@SU-CSLI.ARPA
Tel: 497-3479
!
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
November 21, 1985 Stanford Vol. 3, No. 3
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, November 21, 1985
12 noon TINLunch
Ventura Hall Parsing as Deduction?
Conference Room by Fernando Pereira and David Warren
Discussion led by Mark Johnson (Johnson@su-csli.arpa)
(Abstract on page 2)
2:15 p.m. CSLI Seminar
Redwood Hall Interactive Modularity
Room G-19 Ron Kaplan, Xerox PARC (Kaplan.pa@xerox.arpa)
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Redwood Hall An Introduction to Information-based Complexity
Room G-19 J. F. Traub, Computer Science Department, Columbia
←←←←←←←←←←←←
ANNOUNCEMENT
Please note that there will be no activities and no newsletter on
Thursday, November 28, because of the Thanksgiving Holiday. Thursday
activities will resume on December 5.
!
Page 2 CSLI Newsletter November 21, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
THIS WEEK'S TINLUNCH
Parsing as Deduction?
by Fernando Pereira and David Warren
Pereira and Warren's paper is exceptional in both its scope and its
content. It begins by proposing a translation of conventional phrase
structure rules into (Horn clause) logic that can be given to a
theorem prover, which then uses the logical translation to ``prove''
the well-formedness of sentences with respect to the original grammar
(hence the title, ``Parsing as Deduction'').
Secondly, Pereira and Warren show how standard context-free parsing
algorithms can be generalized as inference procedures that can
ultimately be used to mimic parsers for certain non-context-free
languages: thus showing us how to extend our parsing techniques for CF
languages (which we know fairly well) to non-context-free languages in
a straight- forward way. Thus we can talk about ``the Earley parsing
algorithm for LFG,'' for instance.
And finally, they make some theoretical comparisons between the
parsers so obtained for various different frameworks, and derive
various properties regarding the parsing complexity. Quite a lot for
an eight-page paper!
While not wanting to restrict discussion, I suggest that we
concentrate on only one of these issues, namely the central claim that
parsing can be viewed as deduction. In what sense is it correct to do
so? Does it make sense computationally or psychologically? Or
linguistically or (dare I say it at CSLI) philosophically?
Secondly, what about the logical translations that Pereira and
Warren suggest? Their translation into logical for a rule like
VP --> V NP PP
is something like the following (expressed informally)
a V followed by an NP followed by a PP
implies the existence of a VP.
But consider a sentence like
I saw the man with the telescope
on the reading where the man, not me, had the telescope. The antecedent
of the logical translation of the rule is met, so the VP with the reading
where I used the telescope to see the man should exist, simultaneously
with the VP with the reading where the man has the telescope as well.
That is, we are forced to infer the simultaneous existence of VPs
corresponding to BOTH readings of the sentence.
Is there a problem here? And if so, why doesn't Pereira and
Warren's ``deductive'' run into problems with such ambiguous
sentences? --Mark Johnson
!
Page 3 CSLI Newsletter November 21, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
``Morphological Structure of Kunparlang Verbs''
Carolyn Coleman, (Coleman@csli.arpa)
Thursday, November 21, 10 a.m., Conference Room
Kunparlang verbs are extremely complex morphologically. They
cross- reference Subject and Object functions, incorporate nominal
roots, use `applicative' derivational morphology, carry modal,
directional and aspectual affixes, and inflect for Tense and Mood.
There are two levels of hierarchical morphological structure:
(i) The stem, which carries all morphology having compositional semantics.
(ii) The lexical base, which caries all semantically idiosyncratic
morphology.
Kunparlang verbs undergo two types of reflexive operation which
have a partially complementary distribution and which have different
semantic effects on the verbs to which they apply. With the first
reflexive operation the reflexive subject is always an Actor; with the
second the reflexive subject may be an Undergoer. The second
reflexive operation has a range of meanings which match those of
mediopassive constructions in other languages as well as the reflexive
reading. Both reflexivizing operations are derivations that apply at
the level of the lexical base; given that they have the same
morphological status, there is a problem of how to semantically
characterize them in a manner that will clearly show the semantic
similarities and differences between them. --Carolyn Coleman
----------
PIXELS AND PREDICATES
Cleo Huggins
Wednesday, November 27, 1 p.m., Ventura Seminar Room
Graphic design is a profession that addresses problems with visual
communication. The issues that are covered by this area of work are
significant in the design of symbols.
There are problem solving methods used in design. One is the use
of semiotics, the study of signs. I will describe how this field of
study can be applied to the design process.
Graphic designers also study the interaction of graphic elements.
One might say that design is about harnessing these ``visual basics''
and using them to reach a communication goal. I will look at some of
these elements and indicate how they are used in visual communication.
Designers seldom work on the design of isolated symbols. Often
visual communication takes on the responsibility of systems. Signage
in a building and instructions/directions for a process, are examples
of graphic systems. In the design of a communication system one
develops a graphic language. Consistency is an important element in
the design of this language. I will look at a collection of computer
related graphic elements and emphasize the role of design at a global
level.
I recommend this talk to anyone who:
* Has a tendency to redesign icons to make them witty or clever.
* Believes that all graphic designers are advertising artists.
* Has their cousin design the graphic interface on their applications.
* Thinks that type is generally boring and would rather use
exciting typefaces more often.
* Is interested in how graphic design may be integrated into
work in other fields.
!
Page 4 CSLI Newsletter November 21, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
LOGIC SEMINAR
Proving Properties of Destructive LISP Programs
Ian Mason, Philosophy Dept., Stanford
Friday, November 22, 12:00-1:00, Math. Faculty Lounge, Room 383-N
----------
PIXELS AND PREDICATES
Fragments of Behavior
Luca Cardelli, Digital SRC
Wednesday, December 4, 1 p.m., Ventura Seminar Room
The talk discusses some general issues concerning visual
programming. A particular user interface paradigm is then presented,
where software tools can be visually assembled into larger and more
complex tools. The basic abstraction is called ``Fragment of
Behavior'' which is a thread of control with an interface (for
connecting to other fragments) and an interaction protocol (for direct
user interaction). Composition of fragments involves both a
composition of interfaces and of interaction protocols, and determines
how the different fragments behave and interact concurrently.
The goals are (1) allow different programmers to develop
``features'' of an application independently, including the user
interfaces, (2) provide a library of very basic tools which users can
custom-assemble, and (3) allow users to modify existing compound tools
by adding, removing, or changing features.
----------
SRI TALK
Unification Revisited
Jean-Louis Lassez, IBM Thomas J. Watson Research Center
Monday, November 25, SRI, Room EJ242
There are three main approaches to finitely represent sets of
solutions of equations in the Herbrand Universe. In Robinson's
classical approach the set of solutions is represented by an mgu which
is computed from the set of equations. We introduce a dual approach,
based on Plotkin's and Reynold's concept of anti-unification in which
the finite representation (mgs) is now ``lifted'' from the set of
solutions. A third approach proposed by Colmerauer is based on the
concept of eliminable variables.
The relationships between these three approaches are established.
This study provides an appropriate setting to address the problem
of solving systems of equations and inequations which arises in recent
extensions to Prolog. A key result is that the meta-equation
E = E1 v E2 v ... v En
admits solutions only in trivial cases. Two important corollaries
follow naturally. The first is Colmerauer's property of independences
of inequations. This means that deciding whether a system of
equations and inequations has solutions can be done in parallel. The
other corollary is a negative result; the set of solutions of a system
of equations and inequations can be finitely represented by mgu's only
in trivial cases. Consequently, one cannot obtain a simplified system
which is in ``solved'' form. This is unlike the case when only
equations are considered. Similar properties hold in inductive
inference when one attempts to generalize from sets of examples and
counter-examples.
!
Page 5 CSLI Newsletter November 21, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
FOUNDATIONS OF GRAMMAR
Foundations of Grammar group announces HUG
The FOG group met last week to hear Lauri Karttunen report on HUG,
a new development environment for unification-based grammars on Xerox
1100 workstations. HUG consists of four basic parts: (i) a
unification package, (ii) input/output routines for directed graphs,
(iii) an interpreter for rules and lexical entries, and (iv) an
Earley-style chart parser. All four are written in simple Interlisp-D
for transportability to other dialects of Lisp. The format for
grammar rules and lexical entries in HUG is based on SRI's PATR
system. In addition to its generic core, HUG contains facilities for
grammar development and debugging. These routines take full advantage
of the graphic capabilities of D-machines.
The grammar formalism in HUG is based on PATR. It is designed to
make it easy to encode anything from simple phrase structure grammars
to categorial grammars. From the parser's point of view, a grammar
rule is a single directed graph whose subparts correspond to syntactic
constituents. Lexical generalizations are expressed by means of
templates and lexical rules as in PATR. A Prolog-style treatment of
long-distance dependencies is built in the system.
HUG is now available for use at CSLI. The documentation is
currently in two sections. HUG.DOC (11 pages) in {HEINLEIN:}<HUG>
explains HUG's format for rules and lexical entries. HUGTOOLS.DOC (24
pages) is a user's manual. A section HUG's parser and unification
routine is in preparation. For hard copies of these documents, see
Carol Kiparsky (Carol@csli.arpa).
----------
SUMMARY OF LOGIC SEMINAR
Truth, the Liar, and Circular Propositions, Cont.
Jon Barwise and John Etchemendy (Barwise@csli.arpa)
Friday, November 15, 1985
The previous time John Etchemendy gave an informal introduction to
Peter Aczel's set theory ZF/AFA, and showed how to use it to model the
Austinian conception of proposition. He then discussed how the Liar,
the truth-teller, and other paradoxes and puzzles come out in this
model. This time, I reviewed ZF/AFA very briefly and then used it to
model the Russellian conception of proposition, and discuss how the
same puzzles come out in this model. --Jon Barwise
(The announcement of the above Logic Seminar was accidently omitted
from last week's newsletter.)
-------
∂21-Nov-85 0933 EMMA@SU-CSLI.ARPA Newsletter addition
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 09:33:34 PST
Date: Thu 21 Nov 85 09:26:28-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter addition
To: friends@SU-CSLI.ARPA
Tel: 497-3479
The SRI talk by Jean-Louis Lassez on November 25 will be at 2:00.
-------
∂21-Nov-85 1100 @SU-SCORE.ARPA:ullman@su-aimvax.arpa International CS Institute
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 10:56:29 PST
Received: from su-aimvax.arpa by SU-SCORE.ARPA with TCP; Thu 21 Nov 85 10:44:56-PST
Received: by su-aimvax.arpa with Sendmail; Thu, 21 Nov 85 10:44:49 pst
Date: Thu, 21 Nov 85 10:44:49 pst
From: Jeff Ullman <ullman@diablo>
Subject: International CS Institute
To: faculty@score
I had a visit from Ronald Kay yesterday, and apparently the
GMD-funded "International Inst. of CS" is moving along seriously.
We are among 5 sites being considered, and there will be discussions
on Jan. 8 with Kay and GMD director Szyperski. The outline that
I was able to get from Kay is that the institute would be
independent, initially with funding of 3M/year.
A fraction of that would support postdoctoral visitors from Germany,
who would work on projects also funded from that 3M.
I suspect that in the long run, the directors of the institute
would determine whose projects were funded, and these might be
anywhere. The quid-pro-quo for helping to set it up and hire
the first management would be that the inst. would be located
in Palo Alto and its management and guiding committee would
be dominated by SU people. Further, the initial projects funded
would be SU projects.
Thus, by Jan 8 we need to get together a few, no more than 3,
proposed projects. There should be room for some postdoctoral
visitors, and from what I can gather, Kay and Szyperski would
most like to see new projects that cut across (sub)discipline lines.
I think Nils is going to try to run a discussion of possibilities
next Tuesday, at lunch. I'm going to try to "spearhead" this
proposal if there is sufficient interest that it might fly, so
I'd be happy to know of interest beforehand.
Ernst has some information on GMD which he is going to give
to Rosemary Napier, if anyone is curious.
---Jeff
∂21-Nov-85 1134 RICE@SUMEX-AIM.ARPA 3600 -> Explorer Update.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 11:31:57 PST
Date: Thu 21 Nov 85 11:31:02-PST
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: 3600 -> Explorer Update.
To: aap@SUMEX-AIM.ARPA
Message-ID: <12161073339.30.RICE@SUMEX-AIM.ARPA>
Czar seems to be working now.
Q-Scheme works as well on the Explorers as it does on the 3600s.
Rice.
-------
∂21-Nov-85 1258 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #37
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 12:57:29 PST
Date: 21 Nov 85 1245-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #37
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Thursday, 21 Nov 1985 Volume 1 : Issue 37
Today's Topics:
SIMD vs MIMD (2 messages)
Functional languages on Cray
Job announcement
----------------------------------------------------------------------
Date: Wednesday, 20 November 1985 06:21-PST
From: Bradley C. Kuszmaul <bradley at THINK.COM>
Subject: MIMD vs SIMD - A response I receive directly
The following response was delivered directly to me, and M. Li tells
me that it is ok to send it along with my response on to Parsym. His
meta-response is forthcoming.
-Brad
From: Tony Li <tli@usc-eclb>
Yow! I can't resist that challenge. I can resist sending it to
Parsym for a bit though.
For a start, I'm not sure that I agree with your definition of SIMD.
In your M68000 SIMD machine, there is no real synchronization of
instructions. Even with the common clock, and one macro-instruction,
your machine is not SIMD in the common sense. Each processor would
NOT be doing the same thing at exactly the same time. I cite the
definition of SIMD in [Stone, Intro to Computer Architecture, pg.
321].
In particular, as soon as you begin evaluation of EVAL on all
processors, they will be in sync. However, as soon as you hit a COND,
things will start to happen differently. A traditional SIMD machine
will execute all parts of the COND, disabling processors until they
find a valid branch. Your machine (unless you're doing something that
you're not telling me about) is executing different instructions on
different processors. This is exactly a MIMD machine (Multiple
instruction streams). In some sense, it is irrelevant that all of the
streams started out as a single program. Since each processor will
make its own path (possibly unique) through the code, there are
definitely multiple instruction streams.
On the other hand you could conceivably be disabling processors in the
traditional SIMD (i.e. ILLIAC IV) case. In this case, I argue that
any application which will have substantial computation done by one
branch of a COND will be inefficient.
Cheers,
Tony ;-)
But I DEFINED the instruction set to be the singleton containing the
EVAL instruction. I don't understand what you mean by "your machine ...
is executing different instructions on different processors". At any
given time all the processors are running the EVAL instruction.
I don't really think of a network of 68000's as being SIMD, but it is
possible to argue that they are. The point is that it is hard to draw
the line between SIMD and MIMD.
Perhaps if I start in the domain that definitely seems SIMDish and
gradually move towards MIMD the problem of the beard will become more
apparent (i.e. one whisker is not a beard, two is not a beard, but 4096
whiskers is a beard. Is 2048 a beard? If so is 1024 a beard? If so
is 512 a beard? Where is the dividing line? The same question can be
asked about MIMD. We know that a net of 68000's is not SIMD and that a
connection machine is SIMD. Suppose that we "enhance" the connection
machine instruction set....)
You claim that traditional SIMD machines are allowed to either perform
the current instruction or do nothing (i.e. be disabled). The problem
is that even when all the processors are enabled and all are doing the
same thing (e.g. a bitwise AND operation), the resulting state of each
processor is a function not only of the instruction being broadcast, but
also of the data that was there to start with. Now suppose that we make
the instruction set a little more complex. For example we might see
instructions like
"All processors with a 0 in bit X perform an add, others perform a
multiply"
It seems clear that a machine which runs instructions of
this type could be built. The required bandwidth of the instruction
stream might be increased (e.g. we might supply two of the old
instructions at one time, all processors with a 0 in bit X would perform
the first instruction, all processors with a 1 in bit X would perform
the second instruction). This mechanism still seems to be SIMD (perhaps
2IMD - two instruction multiple data) because the architecture is very
similar to the ILLIAC-IV in that the instruction set is being broadcast
from some central location, and the local location is not doing control
(i..e. no goto's), it is just doing data manipulation)
Now suppose that I really increase the bandwidth of the instruction
stream to the point where I have the following instructions
"Consider the eight bit field starting at bit X.
All processors with 0 in those eight bits do a NOP,
All processors with 1 in those eight bits do an ADD,
' ' ' ' 2 ' ' ' ' ' ' ' ' MULTIPLY,
.... ...
.
.
.
All processors with 256 in those eight bits do a FLOAT MULTIPLY"
Now I have really increased the bandwidth of the instruction set,
because I need to provide 256 instructions to every processor all the
time. There may be implementation difficulties with this scheme, but if
I had a lot of pins on my VLSI chips, I might be able to shove 256
instructions into the chip every clock cycle, each processor could chose
which instruction it will execute bsed on the bits starting at X. Now I
DEFINE a single instruction to be 256 of the old instructions, and I
still have what seems to be a SIMD machine.
I can add a little more hair, and have every processor get the value X
indirectly out of location 0, and change the instruction set so that we
might see the following fragment:
"Let X=<0> in every processor
All processors with 0 in <X> do a NOP and increment <0>
All processors with 1 in <X> do a ADD and increment <0>
...
All processors with 155 in <X> set <0> to be the value computed
during the previous instruction
..."
And it still seems like a SIMD machine. However `opcode' 155 looks
suspiciously like a GOTO in that <0> is set to some arbitrary value, and
on the next instruction, we will be looking at <0> to see what
instruction to execute. It is starting to look more like a MIMD
machine, but given my DEFINITION, this is still a SIMD machine (with a
huge instruction bandwidth)
Now suppose I notice that I always broadcast the same huge instruction.
I.e. that `opcode' 0 always means a NOP, `opcode' 1 always means ADD,
and so on. I have not lost any of the computational power of the
original machine since the `goto' like operation gives me a lot of
power. I, as a hardware engineer, might decide to solve all my
pin-boundedness problems by hard wiring that instruction into the
processors. I might as well since I always broadcast the same thing.
Once I have hardwired that instruction into the chip I have dramatically
reduced the instruction bandwidth, I only need to send the EVAL opcode
which takes no bits to represent. Now I have a network that looks like
a MIMD machine but it is a SIMD machine by the argument of the beard.
Now that I understand how to simulate any MIMD machine by building a
special SIMD machine, I can know how to simulate any MIMD machine with any
SIMD machine. I select all processors that want to run opcode 0 and
then broadcast the opcode 0 instruction. Then I select all processors
that want to run opcode 1 and broadcast the opcode 1 instruction, and so
on. I can perform this simulation with a performance degradation of
only a factor of 256. I wanted to keep my processors busy doing useful
work, so if I say "a processor is busy enough if it is doing useful
work 1/256 of the time" then I am all set.
------------------------------
Date: Thursday, 21 November 1985 12:31-PST
From: AGRE%MIT-OZ at MIT-MC.ARPA
Subject: simd and mimd
Seth Steinberg mentions work Alan Bawden and I did writing a Scheme
interpreter for the Connection Machine. Although Seth's comments are to the
point, I want to make sure nobody thinks we actually intended Scheme as a
serious CM programming language. The Scheme interpreter was just what we
wrote to try out Alan's first CM language, CL1. Having been in MIT Scheme
culture for so many years we figured we knew every possible variant of the
algorithm. (We were wrong, by the way. A CM Scheme interpreter seems to
need an eccentric modularity if arguments are to be evaluated in parallel
without unnecessarily tying up the processors implementing the source code.
Weird.)
We learned some things about programming fine-grained parallel architectures
in general, but I'll just mention what we learned about programming SIMD
machines in particular. The idea behind running a Scheme interpreter (or
any interpreter) on a SIMD machine is to simulate a MIMD machine. If this
is what you want then Scheme is a bad language for it, for three reasons.
One is that you need to multiplex the instruction stream among too many
hunks of interpreter code, one per cell type. (This turns out not to be so
bad if you're careful.) Another is that the primitives are so small that
any decent program takes 50 processors to implement. (Other languages might
be better on this count.)
The third problem with using a Lisp-like language to program a SIMD machine
is the hardest. The Lisp interpreter, and most Lisp programs as well, does
a tremendous amount of dynamic storage allocation. There are gazillions of
cons nodes and stack frames, with a median lifetime near zero. It would be
nice to avoid all this constant reallocation of processors, for a number of
reasons. One is that a rapidly changing process structure is hard to debug.
Another is that the unpredictability of resource requirements makes load
balancing difficult. By the time you do a hairy analysis to find which
processes are competing for resources the processes have finished. Another
is that storage management takes time. The published algorithms for the CM
are pretty poor; presumably you can do better but I'll have to be convinced.
A fourth is that there is a substantial overhead each time you have to set
up a new pattern of router connections. If the connection pattern was
relatively static you could store common router connectivities and change
them incrementally.
These considerations argue for a style of programming in which processors
are assigned roughly permanent functions and their patterns of connectivity
are roughly static. If you take this to an extreme you get connectionism
(more the Rochester sort than the CMU sort). Whether we need to go this far
remains to be seen. Of course the answer to "SIMD vs MIMD" is "SIMD is
better for some things and MIMD is good for others", so we should see what
we can do best with relatively static process organizations. This isn't the
time for detailed speculations on the subject, but here's a hint. Almost
all of the dynamically allocated processors our Scheme interpreter used in
running a program were variable binding nodes. (In a related project,
William Foster verified this assertion statistically for an ACT interpreter
he wrote in CL1.) To a first approximation, you need to do dynamic storage
allocation when you need to bind variables to values. How hard is it to
program without variables?
/phil
------------------------------
Date: Wednesday, 20 November 1985 09:05-PST
From: Paul Kelly <mcvax!kcl-cs!pkelly at seismo.CSS.GOV>
Subject: PARSYM Digest V1 #31
Re: Performance of Lisp on Crays etc.
There is some work going on to produce optimising compilers for functional
languages, to run on Crays.
S.K. Skedzielewski and M.L. Welcome of Lawrence Livermore National
Laboratory, USA, report in their paper "Data Flow Graph Optimisation
in IF1" (in LNCS 201, "Functional Programming and Computer
Architecture", Nancy, 1985), their efforts to compile the
single-assignment language SISAL to Cray code via a standard graphical
intermediate form, IF1.
A single assignment language seems to be (correct me if I'm wrong), a
functional language with syntactic constructs for forms common in
numerical programming.
The paper doesn't give any performance figures relative to other
languages, or machines. Perhaps the authors can be persuaded to tell
us how well it worked?
Yours, Paul Kelly
Dept of Computing, King's College, London, UK.
------------------------------
Date: Wednesday, 20 November 1985 09:12-PST
From: Alfred Hartmann <alfred%mcc-pp at mcc.arpa>
Subject: Position announcement for PARSYM
Microelectronics and Computer Technology Corporation - Position Announcement
----------------------------------------------------------------------------
Parallel Processing Theoretician --
The MCC Parallel Processing Program is seeking a senior research staff
member with a working knowledge of computational complexity theory
(both traditional algorithmic and VLSI theories) who desires to
explore unifying principles and fundamental limits for abstract
parallel processing models. The individual we seek has a strong
theoretical background (especially in the rapidly developing area of
VLSI complexity theory) with a desire to extend existing theories
towards a general theory of parallel processing architecture supplying
asymptotic limits on system power, density (in three dimensions),
interconnection network bandwidths, latencies, and layouts, locality,
efficiency, resource utilization, etc. The ultimate goal is the
development of a theory of parallel processing that establishes
computational metrics and fundamental limits upon the metrics, to be
used in evaluating new paradigms of parallel computation (intended to
replace the von Neumann paradigm of sequential computation).
Typical qualifications would be a doctorate in computer science or
applied mathematics, demonstrated competence in the field, and strong
academic and research associations. Frequent interaction with applied
research and applications in computer architecture, parallel
algorithms, performance analysis and prediction, and computer-aided
design should be expected as part of this position. Recent doctorate
earners with worthy dissertation work in this area are also encouraged
to apply.
Reply with vitae to: George Black, VP and Director
Human Resources
MCC
9430 Research Blvd., Ech. I/200
Austin, TX 78759
(512) 343-0860
------------------------------
End of PARSYM Digest
********************
∂21-Nov-85 1525 @MIT-MC.ARPA:JCMA@MIT-MC.ARPA Classic Quotes (Positivism Assesses Progress in Meaning)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 15:24:17 PST
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 21 NOV 85 18:25:36 EST
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 21 Nov 85 18:21-EST
Date: Thu, 21 Nov 85 18:23:52 EST
From: "John C. Mallery" <JCMA@MIT-MC.ARPA>
Subject: Classic Quotes (Positivism Assesses Progress in Meaning)
To: MINSKY@MIT-MC.ARPA
cc: PHIL-SCI@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].727439.851121.JCMA>
``In sum half a century of talk about meaning has been useless to
scientists and has, if anything, increased confusion among
philosophers.''
-- Mario Bunge, Chapter on Meaning in his Treatise on Basic Philosophy,
Volume 2, Semantics II: Interpretation and Truth, Boston: D. Rediel,
1974, p.43.
∂21-Nov-85 1541 @MIT-MC.ARPA:JCMA@MIT-MC.ARPA Classic Quotes (Positivism Assesses Progress in Meaning)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 15:39:09 PST
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 21 NOV 85 18:25:36 EST
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 21 Nov 85 18:21-EST
Date: Thu, 21 Nov 85 18:23:52 EST
From: "John C. Mallery" <JCMA@MIT-MC.ARPA>
Subject: Classic Quotes (Positivism Assesses Progress in Meaning)
To: MINSKY@MIT-MC.ARPA
cc: PHIL-SCI@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].727439.851121.JCMA>
``In sum half a century of talk about meaning has been useless to
scientists and has, if anything, increased confusion among
philosophers.''
-- Mario Bunge, Chapter on Meaning in his Treatise on Basic Philosophy,
Volume 2, Semantics II: Interpretation and Truth, Boston: D. Rediel,
1974, p.43.
∂21-Nov-85 1639 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH -- Haim Gaifman
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 16:32:58 PST
Date: Thu 21 Nov 85 16:22:22-PST
From: LANSKY@SRI-AI.ARPA
Subject: Next Monday's PLANLUNCH -- Haim Gaifman
To: planlunch.dis: ;
cc: halpern@IBM-SJ.ARPA, moses@IBM-SJ.ARPA
LOGIC OF POINTERS AND EVALUATIONS:
THE SOLUTION TO THE SEMANTIC PARADOXES
Haim Gaifman (GAIFMAN@SRI-AI)
Mathematics Department, Hebrew University, Jerusalem
Visiting SRI International, AI Center
11:00 AM, MONDAY, November 25
SRI International, Building E, Room EJ228 (new conference room)
ABSTRACT:
Imagine the following exchange:
Max: What I am saying at this very moment is nonsense
Moritz: Yes, what you have just said is nonsense.
Evidently Max spoke nonsense and Moritz spoke to the point.
This is rather puzzling, because Max and Moritz appear to have asserted
the same thing, namely: that Max spoke nonsense.
A philosophically more refined version of the puzzle consists in exhibiting
the following two-line text:
line 1: The sentence written on line 1 is not true.
line 2: The sentence written on line 1 is not true.
Our natural intuition is that the self-referring sentence on line 1
is not true (whatever sense could be made of it). Therefore the sentence
on line 2, which asserts this very fact, should be true. But what is written on
line 2 is exactly the same as what is written on line 1.
The very same sentence is judged differently on its two different occurences.
I shall argue that the unavoidable conclusion is that truth values
should be assigned here to sentence-tokens (i.e., the particular occurences of
sentences). In systems (like Kripke's) which assign
only type-dependent truth values one cannot express some facts
easily expressible in common daily discourse. Terrible things
happen in such systems like Holes and even Black Holes.
I shall present a formalism which distinguishes between tokens and
a method of evaluating their truth values (including gaps)
which takes into account the whole network of pointings.
One soon realizes that one should treat more general entities than tokens.
These are the ``POINTERS'' referred to in the title of my talk.
A pointer is any object which is used to point to a sentence (i.e.,
sentence-type). A sentence-token is a special case of a pointer, it points
to the sentence of which it is a token. The basic formalism is extremely
simple. It can serve as a basis for various extensions (with quantifiers
over pointers) and in all cases the resulting language will contain a truth
predicate taking as arguments pointers to its own sentences. There are also
versions with additional modality and epistemic predicates taking pointers
as arguments.
The term ``EVALUATION'' refers to the method by which
truth values are associated with pointers. A basic guiding heuristic
is to regard pointers as names of procedures in some computer program.
The procedure is started by calling the pointer which in turn may call
other pointers, etc. Eventually it returns a value, TRUE, FALSE or GAP.
The procedure is such that, calling `the sentence on line 1' returns GAP, but
calling `the sentence on line 2' returns TRUE. It yields
similarly acceptable results in self referential situations in general, where
any number of pointers can be involved in nasty complicatd loops.
I shall discuss various related topics, other semantic paradoxes, and
show that the smallest number undefinable in less than twenty words
is alive and well and can be defined after all.
P. S. Every sentence in this abstract is of course true.
Question: How about this last very same sentence?
-------
∂21-Nov-85 1704 ullman@su-aimvax.arpa paper recieved
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 17:04:04 PST
Received: by su-aimvax.arpa with Sendmail; Thu, 21 Nov 85 17:01:48 pst
Date: Thu, 21 Nov 85 17:01:48 pst
From: Jeff Ullman <ullman@diablo>
Subject: paper recieved
To: nail@diablo
"The Alexander method, a technique for the processing of recursive
axioms in deductive databases," by Rohmer and Lescoeur, of Bull
Research (that's Machines Bull!).
Apparently the Alex. referred to is "The Great," as in Gordian knot.
It seems to be another version of "magic sets".
∂21-Nov-85 1721 ullman@su-aimvax.arpa vowel fans take note
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 17:16:02 PST
Received: by su-aimvax.arpa with Sendmail; Thu, 21 Nov 85 17:11:17 pst
Date: Thu, 21 Nov 85 17:11:17 pst
From: Jeff Ullman <ullman@diablo>
Subject: vowel fans take note
To: nail@diablo
of the weird configuration in the second author's name, on that
last paper.
Also, I noted in the references to that paper I am listed
as "J. D. Shapiro" close enough...
∂21-Nov-85 1754 WINOGRAD@SU-CSLI.ARPA No ENVIRONMENTS meeting until Dec 9
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 17:54:12 PST
Date: Thu 21 Nov 85 17:47:16-PST
From: Terry Winograd <WINOGRAD@SU-CSLI.ARPA>
Subject: No ENVIRONMENTS meeting until Dec 9
To: friends@SU-CSLI.ARPA, su-bboards@SU-CSLI.ARPA
Sorry to have missed the newsletter with this. There will
be no meeting for the next two weeks. We will resume with
Danny Bobrow (Xerox) on the handling of object storage in LISP
(with COMMONLOOPS) on Dec 9, then Ron Kaplan (Xerox and CSLI) on
the grammar writer's workbench on Dec 16.
--t
-------
∂21-Nov-85 2104 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu ADVANCED COURSE ON PETRI NETS
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 20:56:10 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Thu 21 Nov 85 20:54:09-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Thu 21 Nov 85 20:53:31-PST
Received: by rsch.wisc.edu; Thu, 21 Nov 85 22:36:19 CST
Date: Thu, 21 Nov 85 22:26:54 CST
From: udi@rsch.wisc.edu (Udi Manber)
Message-Id: <8511220426.AA16743@rsch.wisc.edu>
Received: by rsch.wisc.edu; Thu, 21 Nov 85 22:26:54 CST
Subject: ADVANCED COURSE ON PETRI NETS
To: udi@rsch.wisc.edu
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 21 Nov 85 22:36:06 CST (Thu)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
Sent by request of Dr. W. Reisig, GMD:
Preliminary Announcement
ADVANCED COURSE ON PETRI NETS
Theory Applications Relationship to Other Models
Bad Honnef, West Germany, September 8-19, 1986
Petri Nets represent a long and sustained effort to develop concepts,
theories and tools to aid in distributed systems design and analysis.
They are used in many areas of computer science including software
engineering, data base and information systems, computer architecture
and operating systems, communication protocols and computer networks,
process control, and socio-technical systems such as office communication
and man-machine interaction. A rich body of theory has been developed
for Petri Nets. It reflects all major problem areas of distributed
systems and covers many successfully applied principles and analysis
techniques for systems organization.
The course addresses those who are
interested in systems design and would like to use Petri Nets,
familiar with subareas of the theory or the applications of
nets and wish to become acquainted with the whole area,
interested in learning about recent results presented within a
uniform framework,
wanting to learn about successfully applying Petri Nets in
various practical situations.
The course is a successor of the ``Advanced Course on General Net Theory
of Processes and Systems'' held in Hamburg in October 1979.
There will be introductory lectures (accompanied by exercise sections),
survey talks on the most relevant issues as well as presentations on
recent results in theory and applications.
The course will also discuss relationships to other models of concurrent
systems such as COSY, CCS, CSP and ACP. In the field of general systems
design (requirements engineering) we relate nets to techniques such as
SADT.
Several computer-aided tools for editing and analyzing nets will also be
presented.
Also an opportunity will be provided for the participants to discuss
their research problems and results.
Lectures will be given by leading experts in the area. The course will
take place in Bad Honnef, near Bonn, Germany, from September 8th to
September 19th, 1986.
Directors of the course are:
Prof. Dr. W. Brauer, Hamburg University, West Germany,
Dr. W. Reisig, GMD Bonn, West Germany,
Prof. Dr. G. Rozenberg, Leiden University, The Netherlands.
Scientific advisors of the course are:
Prof. Dr. G. Roucairol, BULL, Paris, France,
Dr. P.S. Thiagarajan, Aarhus University, Denmark.
The course will be organized by the Gesellschaft fur Mathematik und
Datenverarbeitung (GMD) under the auspicies of AFCET, AICA, BCS, EATCS,
and GI.
For details and application forms please contact:
Dr. W. Reisig, GMD - Fl, Postfach 1240, D-5205 Sankt Augustin 1, West
Germany; Tel. (02241) 14-2797.
--------------
TN Message #10
--------------
∂22-Nov-85 1248 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #38
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:47:52 PST
Date: 22 Nov 85 1218-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #38
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Friday, 22 Nov 1985 Volume 1 : Issue 38
Today's Topic:
MIMD vs. SIMD
----------------------------------------------------------------------
Date: Thursday, 21 November 1985 12:58-PST
From: Sal Stolfo <sal at CS.COLUMBIA.EDU>
Subject: PARSYM Digest V1 #36
Reply to: the SIMD Camp
From: The MIMD&SIMD Camp
Its probably true that a programmer (or user) can be protected from
most or all details of any machine (thank God). OH, the poor
developer, however!
It is not sufficient to say that the code for the SIMD machine for the
unification problem I posed is the same as for a sequential machine
(modulo intermittent code sequences to disengage processors from the
"else streams" and the "then streams" in conditional expressions).
There were two issues being raised:
1- The unification problem might require the execution of every
possible branch in the program many times because at each branch point
every possible type of object might be present in the SIMD machine.
2- The SIMD program (be it by the hand of a system hacker or a user)
must concern itself at some level sometime with data spanning across
several (possibly many) PE's. In a sequential machine you add one to
an address for the next word of data, or load an index register with a
pointer from memory. That must be done. In an SIMD machine with data
spanning over several PE's, a similar operation must be done which
includes bit passing and disabling instructions in addition to address
computation.
The second issue lies at the heart of the "granularity problem". It is
probably true that if the "task granularity" is larger than the
machine's PE granularity, overhead must be paid by the mismatch. It is
probably also true that if the task granularity is much smaller than
the machine's PE granularity, then parallelism inherent in the task will
be lost (although hardware utilizaton can be quite high). There is a
continum here that waits to be clearly understood from a computational
complexity perspective. The bottom line is, however, that whatever PE
granularity you choose and fix in your machine, you can probably find
a grain-mismatched task that performs oh so poorly. Note in the
extreme case a uniprocessor has a severe grain mismatch with
inherently parallel tasks resulting in maximum utilization and
absolute minimum parallelism.
The remark I made about "speed naming the game" is indeed too
general. "Cost/performance" should be our champion. Thus, relative
cost of SIMD and MIMD devices in terms of DELIVERED MIPS per dollar is
probably the true name of the game. What I mean by DELIVERED MIP is
that the MIP should be measured on the basis of number of useful
objects or results computed per second for the application of
interest. Thus, one should not rate in terms of billion of bit
operations per second, but factor out all of the overhead instructions
burned and lossage due to poor grain fitting to derive the actual
delivery time of useful results. Caution on both sides is in order.
At the risk of not taking my own advice, here is another nuance.
One argument I heard repeatedly is the savings a SIMD PE enjoys by
amortizing one functional unit over several processing sites. It might
be advantageous, however, to trade in all of the area consumed by the
wires to connect the multiple processing sites for a larger, more
powerful, single functional unit that operates on wider data or
performs more useful instructions in one duty cycle. It may,
therefore, be possible that 4 concurrent processing sites would each
have to execute say 4 instructions to equal one instruction by the
single larger processing site. In 4 machine cycles, both compute the
same 4 results.
Let me say this about silicon cost. Silicon area alone is insufficient
to judge cost of a device. A square centimeter's cost may be
insignificant due to amortization, or extremely expensive due to
development effort or cooling requirement. Judging the cost per MIP of
two devices is thus not easily measured by counting square
centimeters. The cost of fabrics by the yard varies according to the
cost of the raw material and labor. Computing by the silicon yard is
no different.
In summary, the large number of parameters involved and the lack of
experience and knowledge available about these issues will undoubtedly
work hard at maintaining this SIMD vs MIMD controversy for some time.
(Parenthetically, I'm a DADO follower.)
Sal Stolfo
------------------------------
Date: Thursday, 21 November 1985 14:45-PST
From: HENRY%MIT-OZ at MIT-MC.ARPA
Subject: SIMD vs. MIMD
GLS: I think that SIMD appears to many people compare unfavorably to
MIMD because it is tempting, in the mind's eye, to picture a single
processor, whether SIMD or MIMD, as being of about the same size. I
think we tend to mentally compare a 1000-processor SIMD machine with a
1000-processor MIMD machine.
GLS's point is well taken -- we tend to avoid mentally factoring in
the cost of processors in terms of their hardware size. There's
another side to this, however, which tends to be unfair to MIMD.
Again, since we are using the word "processor" in both cases, we tend
to assume that the processors are of equal computational POWER. In
the case of connectionist SIMD machines, the processors may be so
small that it may well take a group of these processors to do some
given computational task that a single, larger processor could do.
[Is a Vax a 32-processor SIMD machine?]
My own view is that SIMD vs. MIMD is that it will be a short-term vs.
long-term tradeoff. In the short term, SIMD and shared memory
parallel processors will have a cost advantage, especially for
specialized applications with static process and communication
patterns. In the long term, with more capable processors, more
parallelism and less structured applications, MIMD will win out.
------------------------------
Date: Thursday, 21 November 1985 22:14-PST
From: Simon Kasif <simon at mimsy.umd.edu>
Subject: MIMD vs SIMD
A Non-Folk Theorem on SIMD = MIMD Question
A common folklore in the parallel computation circles asserts that
highly regular computations such as matrix multiplication are most
suitable for SIMD while symbol manipulation is best done on MIMD
machines. The examples given in the MIMD vs SIMD discussion certainly
conformed to this folk tale.
I will argue that this is not necessarily the case.
To prove my point I will use the degree of freedom in the SIMD
definition. Specifically, it is possible to define an SIMD
computation using a shared memory concept (called PRAM in the theory
community and ultracomputer in New York). Now, don't get alarmed. To
achieve practicality, let us assume that we have P processors and M
memories interconnected using a (switching) NETWORK. This SIMD model
is somehow more general than the one where each PE has its own memory.
From now on things are easy. Consider the unification problem
suggested by Sal Stolfo where one needs to unify P terms with a given
term. At each point of execution each processor performs a REGULAR
operation, namely unifying one atomic term with another (or applying a
substitution to an atomic term).
Data Flow languages also can naturally be mapped to this formalism (as
noted by Jack Schwartz and A. Gotlieb). Consider any state of the
data flow graph: Node X passes token MESSAGE(X,Y) to node Y. As
before, this is also a highly regular operation since it can be
implemented in our model by copying MESSAGE(X,Y) from location X to
location Y.
In fact, ANY rewriting system can be naturally mapped to this model by
having every processor always perform a reduction of one term to
another. This includes functional languages (FP, pure LISP), logic
programming languages (pure Prolog, Equational Logic, Concurrent
Prolog, PRISM, Tablog). Needless to say that currently these
languages are the main candidates for supporting so called AI
applications.
Efficiency considerations in this model of computation create the
problem of distributing information on the memories to minimize memory
conflicts. This issue is independent of the SIMD = MIMD question.
Q.E.D (or where did I go wrong)
A CLOSING REMARK:
The observations above support the messages by Brad and V. Pratt.
That is, the question of MIMD vs SIMD is really a question of the
level we are observing the system from. If we look down enough, every
systen looks like it is sending a signal from one gate to another:
SIMD.
Personally, I am a great favorite of MIMD machines for the following
reasons:
1. Flexibility: one can create a MIMD machines by simply connecting
several SIMD machines (uniprocessors).
Example: Consider I/O processors and a CPU: a clear instance of
MIMD.
2. Multi-user environments are clearly easier implemented on SIMD
machines.
3. Two brains are better than one.
------------------------------
Date: Friday, 22 November 1985 02:07-PST
From: Alan Bawden <ALAN at MIT-MC.ARPA>
Subject: SIMD/MIMD and all that jazz
In the context of the current SIMD/MIMD discussion Seth Steinberg
mentioned the paper Phil Agre and I wrote about the Scheme interpreter
we implemented in the experimental connection machine language CL1.
In that paper Phil and I were not trying to address the issues of SIMD
vs. MIMD machines or SIMD vs. MIMD programming languages.
Unfortunately we inadvertently brought attention to those issues by
choosing a Scheme interpreter as our sample program. I doubt if
anyone has ever read our paper without becoming distracted by the
SIMD/MIMD issue. If I had to do that bit of research over again
today, I would choose to implement something more mundane as a
demonstration project. Say a text justifier or an assembler or
something equally dull. (There are other flaws in the paper that make
it hard to understand. Perhaps someday we will revise it.)
Although we did not set out to learn about SIMD vs. MIMD, everybody
wants to talk to us about it. And Phil did think about some of the
issues while he was implementing the Scheme interpreter. Consequently
we now -do- have something to say about it, even though we didn't
write about it in the paper Seth referred to. In fact, we have two
-different- things to say. Phil already made his point in a separate
message to this forum. I have a couple of things to say about the
issues of simulating a MIMD architecture with an interpreter on a SIMD
machine.
A Little Background: CL1
The tool we used to implement the Scheme interpreter is an
experimental low-level connection machine programming language called
CL1. Datatypes in CL1 consist of atomic types such as numbers and
addresses and small record structures that can be built out of atomic
objects. CL1 has primitives for performing operations such as
arithmetic and primitives for sending and receiving messages.
The CL1 compiler processes a collection of descriptions (written in
the Lisp-like CL1 notation) of the behavior of various classes of
processing elements. The output of the compiler can be thought of as
a finite state machine describing every state a processing element can
be in at runtime, when each state-transition is legal, and how each
state-transition is to be effected. ("Every state" does not mean all
the 2↑400 states a processing element with 400 bits of storage can be
in. States have associated state variables that can contain various
values at runtime. For an estimate of the number of states I am
talking about, go and count the labels in an assembly language
program.)
On a SIMD machine (such as a connection machine) such a FSM can be
executed by cycling through each state broadcasting instructions for
the benefit of processing elements that happen to be in that state.
You can think of this as multiplexing the single instruction bus of
the SIMD machine. If the FSM has N states, and each state has about
the same amount of associated code (a good estimate), and you
broadcast instructions in the most simpleminded way, then each
processing element only runs about 1/N of the time.
On a MIMD machine such a FSM can be executed by giving every processor
a local copy of the code which it can use to fetch the instructions
appropriate for its current state. You pay for this convenience in
hardware of course, since each processing element needs to have some
local instruction memory, addressing logic, etc. Also, the bigger the
program you plan to run, the more storage you need at each processing
element.
But SIMD Need Not Be That Slow: A Digression About Scheduling
At first glance it looks as if a SIMD machine will always execute an N
state FSM at 1/N'th the speed of the same FSM on a MIMD machine,
although the SIMD machine will be smaller and easier to engineer. It
does not need to be this bad, however. Given a single bit of feedback
from the processing elements (such as the Global OR flag on a
connection machine), you can avoid broadcasting all of the
instructions for every state. If you broadcast the instructions: "If
you are in state #259, put a 1 on your Global OR output", and the
output of the Global OR network is 0, then you can skip broadcasting
the instructions for state #259. Hopefully there will be lots of
unpopulated states at any given moment.
Furthermore, analysis of the FSM should enable you to skip even
considering broadcasting the instructions for certain states. If
nobody was in state #259 a moment ago, and you just broadcasted the
code for state #17 for which the only possibly transitions are from
#17 to #23 and #17 to #1729, then you -know- that no new cells have
entered state #259. You don't even need to ask. A good model of what
states are populated at what time, kept at runtime, coupled with an
analysis of the FSM, performed at compile time, might make a
significant reduction in the factor of N.
Even cleverer algorithms can be devised for improving the performance
of a SIMD machine executing such a FSM program. We might imagine ways
of deciding what state to schedule next that would tend to cluster
processing elements together in the state graph. This might tend to
increase the number of processing elements listening to the
instruction bus at any given moment, which would effectively reduce
that factor of N.
Nothing in this section represents more than speculation on my part.
I would be very interested in learning about anyone who has
experimented with actual scheduling algorithms for running such FSM
programs on SIMD machines. My intuition is that for a "typical" FSM
you should be able to reduce the factor of N to something more like
log N. But that's just an intuition, I'd really like to see some
simulations.
Why Writing an Interpreter Looks Attractive
Given that the performance loss for a SIMD machine over a MIMD machine
is (perhaps) on the order of the size of the FSM you are trying to
run, it would seem that we can beat the game by writing an
interpreter! That is, we could write a CL1 program that instructs a
collection of processing elements how to behave like the data
structures in an interpreter for some other language, say some
parallel dialect of Scheme.
That single CL1 program would be compiled into a single FSM with
perhaps 25 states. We suffer a factor of 25 performance loss if we
run it on a SIMD machine rather than a MIMD machine, but we save a
great deal of hardware complexity. Furthermore we can run -any-
parallel Scheme program with exactly the same factor of overhead,
rather than writing our code in CL1 where we suffer a different, and
perhaps huge, performance loss for each different piece of code.
Given that we never plan to write another piece of CL1 code again, we
can afford to really bum the hell out of the code for the interpreter.
We can even do the kind of scheduler analysis suggested in the last
section until we have squeezed every last drop of performance out of
that particular FSM. Perhaps we can get down to a factor of 20.
Five years later we are manufacturing our SIMD machine out of some
technology that is 50 times faster anyway and we forget about the
factor of 20 we threw away once. Life is golden, flowers bloom, and
little Cherubs fly about our machine room.
The Fly in the Ointment
But it doesn't work out that way in reality. Our Scheme interpreter
had terrible behavior for a parallel programming language
implementation. Although we never ran it on any actual parallel
machine, it was only necessary to look at the structures in our
simulations to see that we had written a loser. (But please, before
you write us off as a couple of bozos, remember that we didn't care
how badly the interpreter ran. We were trying to learn something
about using CL1. The Scheme interpreter was just a test program.)
We did exactly what we had set out to do: we had written an
-interpreter-. We had written a CL1 program that manipulated as data,
objects that represented Scheme programs. At runtime the data that
represented the text of the FACT procedure would be accessed whenever
anyone anywhere wanted to apply that procedure to anything. Given
that there is a limited bandwidth to the memory holding the text of
the FACT procedure, this results in processing elements queueing up
for their turn.
This is a major problem since it means that no matter how many
processing elements a machine has, only a fixed number of them can be
using any procedure at any given time. By not thinking about this
problem we managed to throw away the whole advantage of building a
parallel computer in the first place.
There were other problems with our interpreter, other places where
processing elements inefficiently queued up waiting for access to
something [see Phil's message in PARSYM V1 #37], but the fact that we
had processing elements waiting for the -text- of procedures I find
especially significant. We are right back where we started, having
trouble distributing instructions to the people who wanted to execute
them!
We could have avoided this bottleneck in one of two ways: we could
have distributed copies of the text of the FACT procedure to everyone,
or we could have broadcasted the text of the FACT procedure
periodically somehow. In the first case we would have reinvented the
MIMD machine, and would have had to pay the price in memory
proportional to the size of the programs we wanted to run. In the
second case we would have had a SIMD machine, and would have suffered
a slowdown (perhaps) proportional to the size of our program.
Any other solutions anyone can devise will, I am sure, have analogs in
hardware architectures we could have built in the first place, and
analogous cost/benefit tradeoffs.
All of this would still be true, by the way, if we were using a MIMD
machine instead of a SIMD machine. If we had decided to build a MIMD
machine, and save money by only giving each processing element enough
memory to store the parallel Scheme interpreter FSM, we would still be
facing exactly the same dilemma here.
The lesson I would draw from this goes something like:
If at some level of abstraction different parts of the machine are
doing different things at the same time, and if those differences
occur dynamically as a result of what data happens to be where (as
opposed to statically where we planned in advance that processing
element 69 would compute pi from 5 PM to 6 PM), and if those
differences are sufficiently diverse, then there will be a problem
distributing something we might as well call "instructions". And you
won't be able to get rid of the problem by any slight of hand tricks.
------------------------------
End of PARSYM Digest
********************
∂22-Nov-85 1455 @MIT-MC.ARPA:MERRY.pa@XEROX.ARPA Re: Classic Quotes (Positivism Assesses Progress in Meaning)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 14:51:05 PST
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 22 NOV 85 17:45:11 EST
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 22 Nov 85 17:42-EST
Received: from Xerox.ARPA by MIT-MC.ARPA 22 Nov 85 16:54:34 EST
Received: from Semillon.ms by ArpaGateway.ms ; 22 NOV 85 11:34:25 PST
Date: Fri, 22 Nov 85 11:34:11 PST
From: MERRY.pa@Xerox.ARPA
Subject: Re: Classic Quotes (Positivism Assesses Progress in Meaning)
In-Reply-To: <[MIT-MC.ARPA].727439.851121.JCMA>
To: "John C. Mallery" <JCMA@MIT-MC.ARPA>
cc: MINSKY@MIT-MC.ARPA, PHIL-SCI@MIT-MC.ARPA
Message-ID: <851122-113425-2280@Xerox>
Dear Chris,
Thanks, but I'm not quite sure I get your meaning.
Diana . . . . I think
By the way my mother's maiden name is Bunge. Hmmmm?
∂22-Nov-85 1902 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu Call for Algorithms Papers
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 19:01:50 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Fri 22 Nov 85 18:29:27-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Fri 22 Nov 85 18:29:25-PST
Received: by rsch.wisc.edu; Fri, 22 Nov 85 20:16:46 CST
Message-Id: <8511222123.AA05439@rsch.wisc.edu>
Received: from WASHINGTON.ARPA by rsch.wisc.edu; Fri, 22 Nov 85 15:23:26 CST
Date: Fri 22 Nov 85 13:21:07-PST
From: Larry Ruzzo <Ruzzo@WASHINGTON.ARPA>
Subject: Call for Algorithms Papers
To: theory@RSCH.WISC.EDU
Status: R
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 22 Nov 85 20:16:24 CST (Fri)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
From: Paul Purdom <pwp%indiana.csnet@CSNET-RELAY.ARPA>
The Fall Joint Computer Conference will meet in Dallas Texas on Nov. 2-6,
1986. The deadline for papers is March 15, 1986. I am organizing the session
on algorithms. There also will be many other sessions on topics of interest to
people in theoretical computer science. An effort is being made to have a
conference of higher technical quality than that of recent general
conferences. If you have some important results and are willing to present
them in a form that is accessable to a wide audience, you are urged to submit
them to this conference. Five copies of your paper should be submitted. You
may send papers on algorithms (other than algorithms for artifical
intelligence) directly to me if you wish. Papers on any topic may be sent to
Harold Stone, Program Chair, FJCC86, IBM T J Waston Research Center, P.O. Box
218, Yorktown Heights, N.Y. 10598.
Paul Purdom, 101 Lindley Hall, Computer Science, Indiana University,
Bloomington, Ind., 47405.
--------------
TN Message #11
--------------
∂22-Nov-85 1941 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 19:30:27 PST
Received: from ames-vmsb.ARPA ([192.12.123.6].#Internet) by SU-SCORE.ARPA with TCP; Fri 22 Nov 85 19:28:22-PST
Date: 22 Nov 85 19:10:00 PST
From: welch@ames-vmsb.ARPA
Subject: SIGBIG
To: super@su-score.arpa
Reply-To: welch@ames-vmsb.ARPA
ASSOCIATION FOR COMPUTING MACHINERY
San Francisco Golden Gate Chapter
"SIGBIG" Special Interest Committee
For Large High Speed Computers
Meetings on the first Wednesday of each month at 7:30 PM. Speakers
who can give insights to various aspects of SUPERCOMPUTING are
featured each month.
Next meeting: Wednesday, December 4,1985, 7:30 PM
Speaker: Denny Cole/Intel Beaverton,ORE (Hypercube)
Topic: The iPSC: An Environment for Concurrent Processing
Location: AXIOM Systems
1589 Centre Pointe Drive
Milpitas, CA
Directions: 17 South to Montague Expressway East. Left from
Montague onto Centre Point (before Capitol).
or 17 South to Capitol Expressway East. Right from
Capitol onto Centre Point (before Montague).
or 680 South to Montague Expressway West. Right from
Montague onto Centre Point (after Capitol).
---------------------------------------------------------------
Tape-recordings of most of the previous may be obtained
in exchange for a tape cassette or $5.00 by contacting:
Mary Fowler (415)261-4058 (rec)
Supercomputing #192, BOX 2787
Alameda, CA. 94501-0787
For information contact Mary Fowler, Chairperson (415) 839-6547
or Mike Austin, Publ. Chair (415) 423-8446
------
∂23-Nov-85 0351 admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 26 (E. Clark, Stanford)
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 23 Nov 85 03:49:30 PST
Received: by ucbvax.berkeley.edu (5.31/1.7)
id AA00636; Thu, 21 Nov 85 12:17:32 PST
Received: by cogsci (5.31/5.16)
id AA09584; Thu, 21 Nov 85 12:14:19 PST
Date: Thu, 21 Nov 85 12:14:19 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8511212014.AA09584@cogsci>
To: cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Nov. 26 (E. Clark, Stanford)
BERKELEY COGNITIVE SCIENCE PROGRAM
Cognitive Science Seminar - IDS 237A
Tuesday, November 26, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``Contrast as a Constraint in Acquisition''
Eve V. Clark
Department of Linguistics, Stanford University
[eclark@su-psych.arpa]
Speakers of a language tacitly subscribe to what I will call
the Principle of Contrast, namely that a difference in form
marks a difference in meaning. This principle, I propose,
offers a powerful tool to children acquiring language. It
serves to constrain the inferences they make about possible
meanings for new forms in the lexicon, in morphology, and in
syntax, by distinguishing them from the meanings of forms
already familiar. If the Principle of Contrast is observed by
children, three major predictions follow: (i) differences in
form should be taken to signal differences in meaning, (ii)
established forms should take priority over innovative ones,
and (iii) gaps in the lexicon should be filled on the one hand
by unfamiliar words and on the other by lexical innovations.
In this talk, I examine these predictions and show that
each is strongly supported by acquisition data. Children
appear to observe the Principle of Contrast from very early. I
will also argue that this principle offers a means for getting
rid of unconventional, over-regularized forms in the lexicon,
in morphology, and in syntax. The assumption that different
forms have different meanings is as indispensable in acquisi-
tion as it is in everyday use.
---------------------------------------------------------------
UPCOMING TALKS
December 3: Bernard Baars, Langley Porter, UCSF
---------------------------------------------------------------
∂23-Nov-85 0352 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Nov. 26 (E. Clark, Stanford)
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 03:52:18 PST
Received: from ucbvax.berkeley.edu by SU-CSLI.ARPA with TCP; Sat 23 Nov 85 03:42:36-PST
Received: by ucbvax.berkeley.edu (5.31/1.7)
id AA00636; Thu, 21 Nov 85 12:17:32 PST
Received: by cogsci (5.31/5.16)
id AA09584; Thu, 21 Nov 85 12:14:19 PST
Date: Thu, 21 Nov 85 12:14:19 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8511212014.AA09584@cogsci>
To: cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Nov. 26 (E. Clark, Stanford)
BERKELEY COGNITIVE SCIENCE PROGRAM
Cognitive Science Seminar - IDS 237A
Tuesday, November 26, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``Contrast as a Constraint in Acquisition''
Eve V. Clark
Department of Linguistics, Stanford University
[eclark@su-psych.arpa]
Speakers of a language tacitly subscribe to what I will call
the Principle of Contrast, namely that a difference in form
marks a difference in meaning. This principle, I propose,
offers a powerful tool to children acquiring language. It
serves to constrain the inferences they make about possible
meanings for new forms in the lexicon, in morphology, and in
syntax, by distinguishing them from the meanings of forms
already familiar. If the Principle of Contrast is observed by
children, three major predictions follow: (i) differences in
form should be taken to signal differences in meaning, (ii)
established forms should take priority over innovative ones,
and (iii) gaps in the lexicon should be filled on the one hand
by unfamiliar words and on the other by lexical innovations.
In this talk, I examine these predictions and show that
each is strongly supported by acquisition data. Children
appear to observe the Principle of Contrast from very early. I
will also argue that this principle offers a means for getting
rid of unconventional, over-regularized forms in the lexicon,
in morphology, and in syntax. The assumption that different
forms have different meanings is as indispensable in acquisi-
tion as it is in everyday use.
---------------------------------------------------------------
UPCOMING TALKS
December 3: Bernard Baars, Langley Porter, UCSF
---------------------------------------------------------------
∂23-Nov-85 1159 ACUFF@SUMEX-AIM.ARPA 3674 and 3647 status
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 11:59:46 PST
Date: Sat 23 Nov 85 11:58:53-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: 3674 and 3647 status
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12161602697.55.ACUFF@SUMEX-AIM.ARPA>
The monitor on 3647 has been replaced and so 3647 should be fully operational
now.
An IO board in 3674 has been replaced and seems to have fixed the network
failure problem. Please use 3674, especially it's network interface (ie. send
and retreive files on it from other machines), and let me know right away if
you have problems.
-- Rich
-------
∂23-Nov-85 1233 ACUFF@SUMEX-AIM.ARPA Air Conditioning in the Welch Road Machine Room
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 12:31:53 PST
Date: Sat 23 Nov 85 12:31:00-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Air Conditioning in the Welch Road Machine Room
To: ksl-LispM@SUMEX-AIM.ARPA
Message-ID: <12161608544.55.ACUFF@SUMEX-AIM.ARPA>
Folks,
We are very short of A/C capacity in the WR machine room, so in the
short term, while solutions are being studied, I'm going to try to keep
some of the lisp machines powered down. Until further notice, I'd like
to turn off unused machines at night and over weekends. In particular,
I'm planning on cutting off all but one of the Explorers in the lobby
of bldg. C, Explorers in offices that are not used during off hours
(Delagi, Brown, Nii, and Delaney), and 3547 (which has no file system).
To avoid accidents, I'd like to take care of the on/off switching myself,
though if you need to get files off of a powered down Explorer, go
ahead and turn it ON (Don't turn anything OFF unless there is an emergency!)
by pressing the button on the FRONT of system unit in. All of the Explorers
have tags on the front identifying them by host name.
Also, if you notice that the machine room seems unusually hot,
please notify me, Nick Veizades, or some other staff person. Don't be
afraid to call me at home.
We realise that this is a gross inconvenience, and are doing all we
can to remedy the problem, so please bear with us.
-- Rich
-------
∂23-Nov-85 1255 JOHNSON@SU-CSLI.ARPA Intro to Computational Linguistics
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 12:55:02 PST
Date: Sat 23 Nov 85 12:47:38-PST
From: Mark Johnson <JOHNSON@SU-CSLI.ARPA>
Subject: Intro to Computational Linguistics
To: linguists@SU-CSLI.ARPA, folks@SU-CSLI.ARPA
Several people have commented that they feel a need
for an introductory course in computational linguistics
and computation here at Stanford.
Such a course might include
- introduction to LISP
- implementing FSAs, and some of their applications
- basic CF parsing techniques (bottom up, earley)
with a practical rather than theoretical emphasis.
I am in principle interested in teaching such a course, although
I may have time constraints, due to thesis, etc. But Spring this
year is a distinct possibility...
So if anybody is interested in having such a course here at Stanford,
let me or Joan Bresnan know.
Thanks,
Mark
-------
∂24-Nov-85 1238 LANSKY@SRI-AI.ARPA tomorrow's planlunch -- 11AM
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 24 Nov 85 12:38:42 PST
Date: Sun 24 Nov 85 12:35:36-PST
From: LANSKY@SRI-AI.ARPA
Subject: tomorrow's planlunch -- 11AM
To: planlunch-reminder.dis: ;
LOGIC OF POINTERS AND EVALUATIONS:
THE SOLUTION TO THE SEMANTIC PARADOXES
Haim Gaifman (GAIFMAN@SRI-AI)
Mathematics Department, Hebrew University, Jerusalem
Visiting SRI International, AI Center
11:00 AM, MONDAY, November 25
SRI International, Building E, Room EJ228 (new conference room)
-------
∂25-Nov-85 0924 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Nov 85 09:24:39 PST
Date: Mon 25 Nov 85 09:06:21-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
cc: library@SU-SCORE.ARPA, maslin@SUMEX-AIM.ARPA
Message-ID: <12162095577.16.RICHARDSON@SU-SCORE.ARPA>
Tomorrow's lunch discussion will be about plans for a proposal to establish
an international institute of computer science, with initial funding from
GMD. (MJH 146 at 12:15)
-------
∂25-Nov-85 1405 BERG@SU-SCORE.ARPA evaluation forms
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 25 Nov 85 14:05:39 PST
Date: Mon 25 Nov 85 14:01:12-PST
From: Kathy Berg <BERG@SU-SCORE.ARPA>
Subject: evaluation forms
To: instructors@SU-SCORE.ARPA, tas@SU-SCORE.ARPA
cc: berg@SU-SCORE.ARPA, modica@SU-SCORE.ARPA
Stanford-Phone: (415) 497-4776
Message-ID: <12162149252.8.BERG@SU-SCORE.ARPA>
We have just received the Fall quarter evaluation forms from
Tau Beta Pi. Please stop by room 030 and get the forms and
instruction sheets from Gina Modica. Please instruct the
students to fill out the top of the form with the pertinent
information about the class, in addition to answering the
questions on the sheet. Please have a volunteer bring
the forms back to either MJH 256 or MJH 030.
Thank you so much for your kind cooperation!
Kathryn Berg
-------
∂25-Nov-85 1600 EMMA@SU-CSLI.ARPA The Next TINLunch
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Nov 85 15:59:58 PST
Date: Mon 25 Nov 85 15:51:51-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: The Next TINLunch
To: friends@SU-CSLI.ARPA
Tel: 497-3479
Here is a description for the December 5 Tinlunch:
``A Humanistic Rationale for Technical Writing''
by Carolyn R. Miller
Discussion led by Geoff Nunberg
This paper is typical of a number of recent articles by
sociologists, rhetoricians, and humanistically-trained writing
specialists, which insist that scientific writing is no less
rhetorical in its means and effects than is writing of an explicitly
belletristic sort. Whether or not we find their arguments compelling,
these articles raise interesting questions for producers and consumers
of technical prose, especially in intellectually self-conscious
disciplines like philosophy, AI, and linguistics. For example: What is
the common understanding of the research enterprise that underlies the
linguistic conventions characteristic of scientific prose, such as the
avoidance of ``I'' and the unusual uses of ``we,'' the frequent use of
impersonal constructions, the numbering of paragraphs, and so on? Can
we apply the apparatus of traditional rhetoric to the evaluation of
the expository usefulness of particular formal languages and
notational conventions? Is there grounds for distinguishing between a
``rhetoric of information,'' concerned with the selection and
arrangement of factual observations, and a ``rhetoric of
description,'' concerned with the linguistic means used to report such
observations?
The TINLunch will be held in the Ventura Conference Room at noon.
-------
∂25-Nov-85 1920 ZEC@SU-CSLI.ARPA linguistcs department colloquium
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 25 Nov 85 19:20:14 PST
Date: Mon 25 Nov 85 19:11:02-PST
From: Draga Zec <ZEC@SU-CSLI.ARPA>
Subject: linguistcs department colloquium
To: folks@SU-CSLI.ARPA
cc: zec@SU-CSLI.ARPA
LINGUISTICS DEPARTMENT COLLOQUIUM
Nick Clements will be giving a talk on
THE PHONOLOGY AND MORPHOLOGY OF
REDUPLICATION IN BANTU
on Tuesday, 26 November at 3:15, in History 217.
There will be a reception following the colloquium in
Joseph Greenberg Room, at Linguistics Department, Bldg. 100
-------
∂26-Nov-85 0745 @SU-SUSHI.ARPA:karp@ernie.berkeley.edu
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 07:45:22 PST
Received: from ucbvax.berkeley.edu by SU-SUSHI.ARPA with TCP; Tue 26 Nov 85 07:40:32-PST
Received: by ucbvax.berkeley.edu (5.31/1.7)
id AA00650; Mon, 25 Nov 85 14:29:30 PST
Received: by ernie (5.31/5.16)
id AA10846; Mon, 25 Nov 85 14:28:57 PST
Date: Mon, 25 Nov 85 14:28:57 PST
From: karp@ernie.berkeley.edu (Richard Karp)
Message-Id: <8511252228.AA10846@ernie>
To: aflb.local@su-sushi.arpa, allmsgs@ernie.berkeley.edu,
csfac@ernie.berkeley.edu, csmsgs@ernie.berkeley.edu,
theory-b@ernie.berkeley.edu, theory-f@ernie.berkeley.edu
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley, Calif. (415)642-0143
Tuesday, November 26
SEMINAR IN COMPLEXITY
2:00 MSRI Lecture Hall
Michael Saks "Dynamic Location Problems on Graphs"
COMPLEXITY COLLOQUIUM
4:00 MSRI Lecture Hall
Umesh Vazirani "A Fast Parallel Matching Algorithm"
∂26-Nov-85 0953 YAMARONE@SU-CSLI.ARPA NO LUNCH WEDNESDAY
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 09:44:31 PST
Date: Tue 26 Nov 85 09:20:16-PST
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: NO LUNCH WEDNESDAY
To: folks@SU-CSLI.ARPA
DUE TO PERSONNEL SHORTAGES AND THE IMPENDING ONSLAUGHT OF
THANKSGIVING CALORIES, THE VENTURA SANDWICH CORPORATION HAS
DECIDED TO SUSPEND OPERATIONS ON WEDNESDAY, NOVEMBER 27.
HAPPY THANKSGIVING!!
SEE YOU NEXT WEEK!!
V.S.C.
-------
∂26-Nov-85 1012 RICHARDSON@SU-SCORE.ARPA CSD Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 10:12:21 PST
Date: Tue 26 Nov 85 08:23:04-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
cc: library@SU-SCORE.ARPA, maslin@SUMEX-AIM.ARPA
Message-ID: <12162349843.19.RICHARDSON@SU-SCORE.ARPA>
Lunch today in MJH 146 at 12:15!
-------
∂26-Nov-85 1050 ullman@su-aimvax.arpa meeting tomorrow
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 10:50:55 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 26 Nov 85 10:44:33 pst
Date: Tue, 26 Nov 85 10:44:33 pst
From: Jeff Ullman <ullman@diablo>
Subject: meeting tomorrow
To: nail@diablo
Let's meet 11AM as usual. Shukey has some ideas on algebraic
approaches to thinking about "all derivations" of a given logic
program, and if there is time I'd like to talk about extensions
to Allen's "polynomial fringe theorem."
∂26-Nov-85 1435 MODICA@SU-SCORE.ARPA Grades
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 14:33:18 PST
Date: Tue 26 Nov 85 14:20:06-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: Grades
To: instructors@SU-SCORE.ARPA
Message-ID: <12162414837.25.MODICA@SU-SCORE.ARPA>
This is to remind you of the procedures regarding End Quarter Reports.
All grades are due within 96 hours of the final exam. All EQRs must
come to me (not Victoria any more) before they are mailed to the
Recorder's Office. If you want a copy of the grade sheet, you should
make a copy before you bring me the original. The Department Copy
remains in the Department Office.
Grades for students not on the EQR should be submitted to me on
Supplementary Report/Grade Change Cards (also known as yellow grade
change cards).
The policy on grades is as follows: End-Quarter grades are final and
not subject to change by reason of a revision of judgment on the
instructor's part; nor are passing grades to be revised on the basis
of a second trial (e.g. a new exam or additional work). Changes may be
made at any time to correct an actual error in computation or
transcribing, or where some portion of the student's work has been
unintentionally overlooked.
Feel free to contact me with questions. I'm modica @score, and e-mail
is the best way to reach me.
-------
∂26-Nov-85 2228 BRESNAN@SU-CSLI.ARPA interactions of morphology, syntax, and discourse
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 22:28:36 PST
Date: Tue 26 Nov 85 22:19:29-PST
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: interactions of morphology, syntax, and discourse
To: folks@SU-CSLI.ARPA
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Next Thursday, December 5, following Thanksgiving, Draga Zec will
present her work on Obligatory Control in Clausal Complements in the
CSLI conference room at 10:00 a.m. She derives the phenomenon of
obligatory anaphoric control from the theory of obviation together
with the semantics of control verbs. Serbo-Croatian, from which much
of her evidence is drawn, beautifully illuminates the two separate
factors in obligatory control, which are obscured in English.
Everyone interested in the syntax and semantics of control
constructions and their implications for linguistic theory is invited.
Written copies of the paper will be available on Monday, December 2 at
the CSLI Receptionists' desk.
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
``Obligatory Control in Clausal Complements''
It is generally held that obligatory control correlates with
the non-finiteness of the complement. Both syntactic and
semantic theories of control have crucially depended on this
particular assumption. My intention is to present a case of
obligatory control into clausal complements, develop an
analysis within the LFG framework, and then explore the
implications of this case for an adequate treatment of
control.
Serbo-Croatian has two types of clausal complements, Type 1
which is generally uncontrolled, and Type 2 which allows
obligatory control with predicates like 'try', 'intend',
'persuade', 'force', etc. It will be shown that Type 2
complements cannot be dealt with in terms of the LFG theory
of functional control, or any other syntactic theory of
control. Rather, it will be argued that these complements
are a clear case of what in LFG is referred to as anaphoric
control. Certain differences in anaphoric binding properties
between the two complement types are attributed to the
phenomenon of obviation which is found with Type 2 but not
with Type 1 complements.
Since anaphoric control cannot capture the systematic
controller/controllee relation characteristic of obligatory
control, one will have to make reference to the semantic or
more precisely, thematic properties of control-inducing
predicates. This may have implications for syntactic
theories of obligatory control, whose aim is to make
predictions about controller/controllee relations solely in
syntactic terms. This case will also be relevant for the
semantic analyses that account for control solely in terms
of entailment. --Draga Zec
-------
-------
∂27-Nov-85 0015 EMMA@SU-CSLI.ARPA Ventura Security
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 00:15:28 PST
Date: Tue 26 Nov 85 15:09:33-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Ventura Security
To: folks@SU-CSLI.ARPA, consultants@SU-CSLI.ARPA
Tel: 497-3479
Please be extra careful about locking up over the Thanksgiving break.
Remember to lock both your office door and the exit door of the building
when you leave.
Emma Pease
-------
∂27-Nov-85 0842 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #39
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 08:42:45 PST
Date: 27 Nov 85 0830-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #39
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 27 Nov 1985 Volume 1 : Issue 39
Today's Topics:
SISAL
Connection Machine Programming
Call for Papers -- Principles of Distributed Computing
----------------------------------------------------------------------
Date: Thursday, 21 November 1985 19:51-PST
From: eugene at AMES-NAS.ARPA (Eugene Miya)
Subject: SISAL
SISAL does not run on the Cray. Yet. God, we wish it did. SISAL is
a joint project between DEC, LLNL, U of Manchester, CSU Fort Collins
and several sites willing to be mice: NASA Ames among them. We can
run SISAL on several VAXen. Last year, we had a dataflow workshop
with Jack Dennis. SISAL is a cleaned up version of Jack's VAL
language. We had physicist users willing to run SISAL or VAL, but
their 3-D problems quickly exceeded the capability to realistically
run problems on a VAX. It would take days of VAX time to get some
type of Cray run comparison, say "programmability." The Cray 2 with C
and Pascal (the latter vectorizing) introduces an interesting
prospect: SISAL on the 2. [I thought about bringing up Tim Budd's APL
on the 2 BTW but w/o hardware vectorization (C does not vectorize yet,
and it would be an exercise for the APL user :-))]. The 2 running
UNIX brings a candy store of different packages never in this arena
(we have XLISP: 1st non-Cray package brought up).
If you want details of SISAL the contact is skedz@lll-crg (Steve
Skedzielewski is the local driving force behind dataflow at Livermore
now.
Comment on the SIMD vs MIMD discussion: not much code, but the
definitions of MIMD and SIMD seem interesting. My boss was an ILLIAC
IV programmer. While he agrees MIMD is "more powerful." He views the
discussion as something of a joke. One of the reasons SIMD was more
powerful on the ILLIAC was the capability for higher than Cray I/O
speeds (4096 head disks). The numerical world appears to view MIMD at
two levels: simple IF-statement processing which seems to easily break
vector and parallelization, and true general purpose MIMD (few real
MIMD algorithms of high order [Monte Carlo, some pruning]). Keep up
the discussion, its amusing to watch and let us know when you can
sustain a computation rate greater than large memory Crays [note: no
use of units].
:-)
--eugene miya
NASA Ames Research Center
------------------------------
Date: Tuesday, 26 November 1985 05:49-PST
From: Seth Steinberg <sas at BBN-VAX.ARPA>
Subject: Golly!
When I read the Connections Machine book I came away fascinated but
very frustrated. The description was almost completely at the
hardware level but aside from a bit of handwaving about xectors and
storage allocation nothing was said about the SOFTWARE! When I read
Agre and Bawden's MIT AI Memo (Was it #786?) I was able to understand
how a connections machine could be programmed. You can learn a lot
more from a few hundred lines of code than a few dozen papers full of
algorithms.
I would like to thank Phil Agre, who sent me a copy of this paper, and
Alan Bawden, who should publish his bit bucket since it contains some
of the most interesting code I have read for writing this gem. I hope
this discussion encourages more writing on SOFTWARE ENGINEERING for
parallel computers.
Seth Steinberg
------------------------------
Date: 18 Nov 85 14:23:51 PST
From: HALPERN@IBM-SJ.ARPA
To: arpanet-bboards@mit-mc
Subject: Call for Papers -- Symposium on Principles of Distributed Computing
[Forwarded by Steven A. Swernofsky <SASW at MIT-MC.ARPA>]
CALL FOR PAPERS:
5th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing
(PODC)
Calgary, Alberta, Canada
August 11-13, 1986
Original research contributions are sought that address fundamental
issues in the theory and practice of distributed and concurrent
systems. Topics of interest include, but are not limited to, the
following aspects of concurrent and distributed systems:
* Principles of distributed computation derived from
practical experience with working systems
* Algorithms and complexity
* Specification, semantics, and verification
* Programming languages and programming language constructs
* Fault tolerance
Important Dates:
Jan. 31, 1986: Abstracts due
Apr. 11, 1986: Authors informed of acceptance or rejection
May 16, 1986: A final copy of each accepted paper due, typed on special
forms for inclusion in the conference proceedings
Please send ELEVEN copies of a detailed abstract
(not the complete paper), with the address,
telephone number, and NET ADDRESS (if available) of a
contact author on the cover page, to the program chair:
Dr. J. Halpern
Department K53/801
IBM Almaden Research Center
650 Harry Road
San Jose, CA 95120-6099
The abstract should be no more than 10 DOUBLE-SPACED TYPEWRITTEN PAGES.
It must include a clear description of the problem being discussed,
comparisons with extant work, and a section on major original
contributions. There should be enough detail provided for the
program committee to make a decision.
SUBMISSIONS ARRIVING LATE OR DEPARTING SIGNIFICANTLY FROM THESE
GUIDELINES RISK REJECTION WITHOUT CONSIDERATION OF THEIR MERITS.
The Program Committee consists of:
David Cheriton, Stanford
Cynthia Dwork, IBM Almaden
Nissim Francez, Technion
Hector Garcia-Molina, Princeton
Joseph Halpern, IBM Almaden
Butler Lampson, DEC
Richard Ladner, U. of Washington
Paul Leach, Apollo Computer, Inc.
Michael Merritt, AT&T Bell Laboratories
Doron Rotem, Waterloo University/Lawrence Berkeley Labs
Sam Toueg, Cornell
Conference Chair: Ernest Chang, Alberta Research Council
Publicity Chair: Tiko Kameda, Simon Fraser University
------------------------------
End of PARSYM Digest
********************
∂27-Nov-85 1056 ACUFF@SUMEX-AIM.ARPA Patches for Some Explorer Bugs
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 10:54:23 PST
Date: Wed 27 Nov 85 10:52:31-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Patches for Some Explorer Bugs
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12162639191.25.ACUFF@SUMEX-AIM.ARPA>
I've made up patches for 7 of the bugs in our current software (2.12).
I advise everyone to do (make-system 'ksl-patches :noconfirm) in her
login-init.lisp. As always, please let me know if there are problems.
Also, a fairly complete list of known bugs can be found in
Sumex:<LispM>Exp-Pre2.bugs.
-- Rich
-------
∂27-Nov-85 1411 ullman@su-aimvax.arpa algebra of derivations
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 14:11:29 PST
Received: by su-aimvax.arpa with Sendmail; Wed, 27 Nov 85 14:06:26 pst
Date: Wed, 27 Nov 85 14:06:26 pst
From: Jeff Ullman <ullman@diablo>
Subject: algebra of derivations
To: nail@diablo
Following up on what Shukey said this morning, perhaps the
most interesting algebraic object is the thing that describes
the pattern(s) of the variables in the strings of literals
that get generated. For example, is there a tableau whose
pattern must match the variables in successive literals?
e.g., if the string looks like p(X1,X2) p(X2,X3) p(X3,X4)...
we could describe it by the tableau
b1 b2
b2 b3
Happy thanksgiving to all.
∂27-Nov-85 1446 SCHOLZ@SU-SUSHI.ARPA meeting of the minds
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 14:46:04 PST
Received: from SU-SUSHI.ARPA by su-aimvax.arpa with Sendmail; Wed, 27 Nov 85 14:41:19 pst
Date: Wed 27 Nov 85 14:41:17-PST
From: Karin Scholz <SCHOLZ@SU-SUSHI.ARPA>
Subject: meeting of the minds
To: mugs@SUMEX-AIM.ARPA
Cc: nail@SU-AIMVAX.ARPA
Message-Id: <12162680837.28.SCHOLZ@SU-SUSHI.ARPA>
allen vangelder has graciously agreed to speak and to answer questions
on the nail! project at the upcoming mugs (dec9, 4pm, mjh252).
y'all please be nice to him.
nail! meetings are conducted according to serial transmission protocol,
interrupts disabled, 1200 baud, 60db. allen is probably unaccustomed
to screaming, clawing, kicking, and cries of the form "that's trivial!",
and "that is subsumed by X!" and "that's not what i want to know!" from
bulgy-veined audience members oblivious to concurrency control issues.
by the way, jeff mentioned that anyone who is interested in attending
the nail! meetings on wednesdays at 11am is welcome.
karin
-------
∂27-Nov-85 1648 LANSKY@SRI-AI.ARPA future plans for PLANLUNCH
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 16:47:56 PST
Date: Wed 27 Nov 85 16:45:43-PST
From: LANSKY@SRI-AI.ARPA
Subject: future plans for PLANLUNCH
To: planlunch.dis: ;
Due to various circumstances, there will be NO planlunch this coming Monday.
The schedule for the rest of the quarter and for early next quarter follows:
Monday, Dec. 2: BREAK
Monday, Dec. 9: Lenny Wesley
Monday, Dec. 16: Marcel Schoppers
HOLIDAY BREAK
Monday January 20: Dave Smith
Monday January 27: Peter Ladkin
Don't forget: if you would like to give a talk next quarter,
please let me know!
-Amy Lansky (LANSKY@SRI-AI)
-------
∂27-Nov-85 1708 BSCOTT@SU-SCORE.ARPA Tuesday Faculty Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 17:06:32 PST
Date: Wed 27 Nov 85 17:05:29-PST
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: Tuesday Faculty Lunch
To: Faculty@SU-SCORE.ARPA
cc: BScott@SU-SCORE.ARPA
Message-ID: <12162707088.12.BSCOTT@SU-SCORE.ARPA>
Since there have been so many concerns expressed about the new Patent Agree-
ment and Stanford's patent and copyright policy, I have arranged to have two
representatives from the Sponsored Projects Office present at Tuesday's
faculty lunch on December 3 to respond to your questions. I am not sure just
who will be here to represent SPO, but I will let you know on Monday.
If you do have questions, I urge to you attend.
General discussion had been planned for next week, but Nils agrees that the
SPO visit is probably a good idea.
Betty
-------
∂28-Nov-85 1917 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #40
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 Nov 85 19:17:47 PST
Date: 27 Nov 85 2035-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #40
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Thursday, 28 Nov 1985 Volume 1 : Issue 40
Responses to PARSYM Hardware Survey:
Aquarius (Berkeley)
Tagged-Token Dataflow Architecture and
Multiprocessor Emulation Facility (MIT)
Butterfly (BBN)
[This digest begins the publication of the responses to the PARSYM
Survey on Hardware for Parallel Symbolic Computation (V1 #33). Five
responses have been received so far. Because of message size
limitations, the five have been divided into two digests: three
responses here, two in a subsequent digest. Thank you very much,
respondents, for taking the time to let PARSYM know about your work.
I'm sure PARSYM readers will be impressed and enlightened by the
information you have provided.
I hope these early returns will stimulate other PARSYM readers to
reciprocate. Further contributions are always welcome. -- BD]
----------------------------------------------------------------------
Date: Saturday, 16 November 1985 09:13-PST
From: fagin at dali.berkeley.edu (Barry Steven Fagin)
Subject: Response to survey about hardware
Greetings fellow readers!
Here's my response to the digest's survey on hardware for parallel
symbolic computation:
> What computer hardware are you using or developing?
We're working on the Aquarius multiprocessor, a heterogeneous computing
system with multiple processing elements for symbolic and numeric
computation. The heart of the system is a VLSI Prolog processor chip,
based on a TTL version designed and built here.
> What are its components (processors, memory) and how many; how do the
> processors and memory communicate?
We envision 16 processors connected with 16 main memory modules through
a crossbar. Each processor has a cache between it and the
crossbar. There is also a separate bus connecting the processors
to a synchronization memory, with snooping caches between the bus
and the processors.
> SIMD/MIMD? Shared memory or distributed memory?
MIMD, shared memory.
> What model of concurrency are you investigating with this system?
A simplified version of Conery's AND/OR process model.
Part II (Optional, for extra credit)
> 0. Project summary:
> What model of concurrency (e.g., dataflow, communicating sequential
> processes, actors, futures, etc.) is your work based on? What
> language, if any, are you using in your work?
We're using conventional Prolog. Clause processes are responsible
for AND-parallelism, procedure processes for OR-parallelism.
Processes communicate with one another by sending messages to parents
and children.
> 1. Architectural classification:
> SIMD or MIMD?
MIMD.
> 2. Processing elements:
> Describe each processor ...
The processor is a VLSI version of a TTL Prolog processor designed and
built here at Berkeley. Simulations indicate 400 KLips on
deterministic concatenate benchmark. Each processor addresses a
maximum of 16 megabytes. A functional and a register transfer level
simulator, both written in C, exist for the uniprocessor, and a
functional simulator exists for the multiprocessor.
Our system is a heterogeneous one, consisting of several parallel
Prolog processors (PPP's), processors for numeric computation,
and a processor for I/O and operating system functions.
> How many processors are there in the minimum and maximum configurations?
> How many are you currently using?
We envision 16 processors in the final system. The simulator as it stands
now assumes an infinite number of processors are available.
> 3. Memory system:
> Describe how memory is distributed and accessed in the system ...
There are 16 main memory modules connected to the processors through
a crossbar, and a synchronization memory connected to the processors
over a bus. There is a single address space. Traffic to main
memory from each processor is intercepted by a write-through cache, to
the synchronization memory by a snooping cache.
> What are the minimum and maximum amounts of memory? How much are you
> currently working with?
Unknown at this point. The simulated version assumes infinite memory.
> 4. Communication system:
> How are processors connected to each other and to memory? Describe in
> terms of topology (e.g., tree, systolic array, pipe, grid), switching
> type (e.g., LAN, bus, Butterfly switch), and throughput (e.g., bus
> transmission rates, time to access memory on remote nodes, time to
> broadcast a message to all nodes).
Can't answer these yet.
> 5. Synchronization:
> What hardware mechanisms does the system supply to support
> synchronization?
We haven't decided yet, but we'll probably use test and set.
> 6. Pragmatics
> Is your system geared towards either specific programming languages or
> applications?
We're looking for problems that can be solved rapidly by processing in
both the symbolic and the numeric domain. Currently, we're using Prolog
as the language for symbolic processing.
> Is the hardware of your system generally available or, if custom-made,
> likely to be available in future?
We're working on agreements with companies to sell the chip we produce.
Will keep you posted.
--Barry Fagin
(fagin@berkeley)
------------------------------
Date: Wed, 20 Nov 85 10:50 EST
From: Soley@MIT-MC.ARPA
Subject: PARSYM Digest V1 #33
The Third PARSYM Survey: Computer Hardware
There are essentially two major projects taking place in the Computation
Structures Group (formerly Functional Languages & Architectures Group)
at LCS (MIT) under Professor Arvind. The end goal of one is a dataflow
machine known as the Tagged-Token Dataflow Architecture (TTDA), a
decidedly MIMD fine-grain-computation (though complex processors [at the
moment]) model. The other project, known as the Multiprocessor
Emulation Facility (MEF), is a simulation/emulation testbed for
multiprocessor architectures. The TTDA is being modelled under the MEF
environment, as well as under simulation on an IBM 4381.
Part I (Easy)
What computer hardware are you using or developing?
The TTDA uses imaginary hardware (which we will construct when we
understand it). The MEF uses any number of Lisp machines (we are
targeted at 8 Symbolics 3600's and 64 TI Explorers; we currently have 3
3600's, 5 3670's, and about 20 Explorers). All are connected via
Ethernet (Chaos protocols), and the Explorers are also connected via a
globally clocked circuit-switched 3Mbyte/second/circuit network of our
own concoction, though it is based on the BB&N Butterfly's network. We
are also working on a network interface card for the Explorer (called
NuCA, for Nubus Channel Adapter) and a packet-switching hypercube
topology network for the Explorers.
SIMD/MIMD? Shared memory or distributed memory?
Both the TTDA and the MEF are MIMD. The TTDA uses a distributed memory
model known as "I-structures." The MEF was originally intended
primarily to model packet-communicating (distributed memory)
architectures, but will likely do well with shared memory designs with
our new communication networks.
What model of concurrency are you investigating with this system?
TTDA: Obviously, dataflow (fine-grained parallelism with no programmer
specification of that parallelism). MEF: Anything goes.
What would you like to see in your next hardware system?
Lower-latency interconnection network.
Part II (Optional, for extra credit)
0. Project summary:
What model of concurrency (e.g., dataflow, communicating sequential
processes, actors, futures, etc.) is your work based on? What
language, if any, are you using in your work?
TTDA: Dataflow. MEF: Anything goes. The TTDA project is using the
language ID to express programs, though the emulation of the processor
is done in Lisp. There are also simulations of the machine in Lisp and
Pascal. The MEF is written entirely in Lisp, and emulations for the MEF
are also written in Lisp.
1. Architectural classification:
SIMD or MIMD?
Both MIMD.
2. Processing elements:
Describe each processor ...
TTDA: approximately 68000 power. MEF: each host is a Lisp machine.
How many processors are there in the minimum and maximum configurations?
How many are you currently using?
TTDA: Min one processor, max probably several thousand. Currently
simulating and emulating between one and sixteen. MEF: Min one
processor, max 256. Currently using between one and 28.
3. Memory system:
Describe how memory is distributed and accessed in the system. ...
TTDA: The only non-local memory access is through a mechanism called
I-structures. The dataflow model is highly resistant to memory latency,
for reasons that I won't go into here (feel free to ask for references).
MEF: though originally intended for message-passing (no global memory),
we will be experimenting with remote memory reference over our faster
connection media. Many different styles are being considered.
What are the minimum and maximum amounts of memory? How much are you
currently working with?
MEF: Each of our Lisp machines has between four and six megabytes.
4. Communication system:
How are processors connected to each other and to memory? Describe in
terms of topology (e.g., tree, systolic array, pipe, grid), switching
type (e.g., LAN, bus, Butterfly switch), and throughput (e.g., bus
transmission rates, time to access memory on remote nodes, time to
broadcast a message to all nodes).
MEF: Ethernet, circuit switch based on Butterfly switch, future packet
switch of our own design (in conjunction with on-site IBM engineers).
5. Synchronization:
What hardware mechanisms does the system supply to support
synchronization?
TTDA: Tags on the tokens, and a unit known as "waiting-matching store."
6. Pragmatics
Is your system geared towards either specific programming languages or
applications?
The TTDA is geared toward functional languages, such as ID (Irvine
Dataflow). The MEF is geared toward Lisp.
Is the hardware of your system generally available or, if custom-made,
likely to be available in future?
TTDA: Not generally available. MEF: Generally available.
If you're now using a multiprocessor system, how does the architecture
of your development system correspond to your research target
architecture?
The TTDA and the MEF (on which the TTDA is emulated) are both comprised
of relatively complex processors, with high-bandwidth interconnections.
------------------------------
Date: Sat, 23 Nov 85 02:06 EST
From: "Curtis A. Scott" <cscott@BBN-VAX.ARPA>
Subject: Survey #3 reply
Disclaimer:
Since I am not only a user of the hardware described, but an employee
of the company which builds it (BBN), my views may be assumed to be
biased. However, my views are just that-- my views-- and are not to
be taken as BBN statements or policy.
The Third PARSYM Survey: Computer Hardware
(Reply to PARSYM-Survey@SUMEX-AIM.ARPA)
Part I (Easy)
What computer hardware are you using or developing?
A: We are using BBN's Butterfly.
What are its components (processors, memory) and how many; how do the
processors and memory communicate?
A: 1 to 256 68000 processors, ultra-high-speed packet-switching interconnect
network.
SIMD/MIMD? Shared memory or distributed memory?
A: MIMD. Memory mapping is at the discretion of the systems programmer.
Most applications run with code and a value cache in local memory
and a global shared linear address space. While it is possible
to fetch and execute code across the switch, it's not a winning
strategy.
What model of concurrency are you investigating with this system?
A: FUTURE-based.
What would you like to see in your next hardware system?
A: Faster processors, and/or more processors. Larger address space
(the processor is limited to 24 bits of virtual byte address).
Part II (Optional, for extra credit)
0. Project summary:
What model of concurrency (e.g., dataflow, communicating sequential
processes, actors, futures, etc.) is your work based on? What
language, if any, are you using in your work?
A: We are building a FUTURE-based version of Scheme (which we call
"MultiScheme", since it is derived from both Scheme and Bert
Halstead's Multilisp work). This is intended to serve as a
base for a concurrent Common Lisp and experimentation with
other concurrent programming systems. Scheme is implemented
in a combination of 'C' and assembler; the Scheme compiler emits
68000 code for simple operations.
1. Architectural classification:
SIMD or MIMD?
MIMD. We doubt that any SIMD machine can efficiently use its hardware
performing general-purpose symbolic computation, although as
subengines SIMD machines will be quite useful.
2. Processing elements:
Describe each processor ...
A: The BBN Butterfly is built of processor nodes plus an ultra-high-speed
interconnect network. Each node has a 68000 (or 68020) processor, a
node controller, and some amount (typically 1-4 Meg) of local memory.
The processor node controller is a microprogrammed bitslice processor.
The network nodes are single custom VLSI chips. The interconnect
network for 16 processor nodes fits on a single card.
How many processors are there in the minimum and maximum configurations?
How many are you currently using?
A: Butterflies can be run in any configuration from 1 to 256 processors.
We use a 16-processor machine for most of our development, and use
the 128-processor machine at BBN occasionally.
3. Memory system:
Describe how memory is distributed and accessed in the system. ...
A: The node controller mediates all memory references made by the processor,
performing the mapping of local and distant memory into the address
space of processes running on that processor and handling requests
from other processors. If a reference is non-local, the node
controller stops the processor, sends a memory request through the
network to the processor on which the physical memory for that virtual
address actually resides, and restarts the processor when the value
returns. This is transparent to the processor and typically slows
a 16-bit nonlocal read from the normal local 1 usec to 4-5 usec.
There is no hardware cache. Snoopy caches are not possible on
non-bus-based systems, but bus-based systems will never have
sufficient bandwidth for multiprocessing on the scale we
envision.
What are the minimum and maximum amounts of memory? How much are you
currently working with?
A: The minimum is a single node with 256K bytes. This size is no longer
being built.
The maximum is currently 256 processors X 4 Meg = 1 Gigabyte of
memory. Such a machine has not yet been built; the maximum
configuration to date has 128 processors X 1 Meg = 128 Megabytes.
4. Communication system:
How are processors connected to each other and to memory? ...
A: Butterfly switch. Time to read memory varies depending on
network load, but usually is ~5 usec. Writes take
about half that time since a return packet is unnecessary.
If "broadcasting a message to all nodes" is viewed as the
time it takes to notify a process on each node that some event
has occurred, this time is minimized (on the current machines) by
simply writing to a flag residing in the local memory of each processor
node. This takes approximately 8 * NumProcessors usecs. There are
also higher-level event notification mechanisms available, but in the
simplest case a write is cheaper. Total best-case throughput of the
network on a 128-processor machine is around 32 Gb, and scales with
the number of processors. Switch congestion is rarely a problem,
but memory hotspotting (when some piece of physical memory
accessed through a single node controller is used heavily by
other processors) can cause performance degradation for naively-
parallelized programs.
5. Synchronization:
What hardware mechanisms does the system supply to support
synchronization?
A: Simple atomic operations (add, subtract, ior, xor) are implemented
in microcode, and are somewhat slower than simple reads and writes,
typically <30 usec. The simplest form of semaphore uses atomic←ior
to get a flag and simple write to clear it, and thus takes <35 usecs
of overhead.
Microcode-supported high-level constructs include Events (an object
on which a process may wait, and which may be atomically posted
with a single datum), and DualQueues, which have atomic EnQueue and
DeQueue operations and allow processes to leave Events to be posted
if there is no data available in the queue.
6. Pragmatics
Is your system geared towards either specific programming languages or
applications?
A: The hardware was originally built for use as a voice packet switching
node, but is now completely general-purpose. Systems programming
and applications are now programmed mostly in 'C', but our project
aims to make the machine more programmable for AI and 'symbolic'
(yes, I know, all computing is symbolic) applications.
Is the hardware of your system generally available or, if custom-made,
likely to be available in future?
A: The hardware is available to anyone who wants to plunk down money.
Most machines are currently installed in university and defense
contractor labs.
If you're now using a multiprocessor system, how does the architecture
of your development system correspond to your research target
architecture?
A: Exactly, since our 'application' is a good symbolic programming
environment for this particular machine.
What are the advantages of your hardware setup, particularly for the
problems you are investigating? What are the disadvantages? Is there
a system that would better meet your needs?
A: Advantages: Direct access to the hardware developers and many of
the Butterfly's current users; reliable hardware; rapidly improving
system amenities (e.g., Internet access to Butterflies, file
servers).
Current disadvantages: no disk drives directly attached to the
machine; compilation currently is done on a VAX or Sun and files
downloaded via Ethernet to the Butterfly.
There is no stable, available multiprocessor that I am aware of which
has the capacity of the Butterfly in useful interconnect bandwidth
and processing power. Since our project is intended to result in a
system for the fastest possible general symbolic computing, this machine
is the best engine for it.
------------------------------
End of PARSYM Digest
********************
∂29-Nov-85 0848 NILSSON@SU-SCORE.ARPA Computing Needs
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Nov 85 08:48:45 PST
Date: Fri 29 Nov 85 08:47:54-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Computing Needs
To: faculty@SU-SCORE.ARPA
Message-ID: <12163140794.8.NILSSON@SU-SCORE.ARPA>
On November 1, Les Earnest sent a message to the faculty list requesting
5 year projections of computer facility needs, to be used in several
planning efforts. To date, the following responses have been received
Activity Respondents Remarks
Comp. Linguist. T. Winograd
& Specification
Analysis of D. Knuth
Algorithms
- R. Floyd Minimal support needed
A.I. & Formal L. Earnest
Reasoning & J. McCarthy
Knowledge T. Rindfleisch Instructional computing sketchy
Systems Lab. & P. Rosenbloom
Of course, we are not going to assume that a "no response" means
that you will have no computing needs during the next 5 years--we'll
just have to try to guess what they might be. I think we'll be
able to guess the "average needs" as well as anyone, but if you
know about special needs, now is the time to get them into Les.
The reason for being concerned about this now, is that budget
forecasts are being submitted, temporary (1985-1990) space needs
are being planned, and certain decisions regarding our computing
environment and how it ought to be organized are being made. We take
our job to be one of creating the flexibility we all want during the
next few years--not one of thinking up constraints on what we do. BUT,
we do need to hear from you to do that job well.
If your projected needs have not been reported yet, please send them to
Les @SAIL not later than December 2. If we don't know what you need,
we can't make adequate plans for space, computers, and staffing.
Thanks, -Nils
-------
∂29-Nov-85 1028 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books--CS
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Nov 85 10:28:44 PST
Date: Fri 29 Nov 85 10:27:36-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books--CS
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA, cs%Playfair@SU-SCORE.ARPA
Message-ID: <12163158945.9.LIBRARY@SU-SCORE.ARPA>
Parallele Algorithmen. Informatik-Fachberichte No. 64. by F. Hossfeld.
QA184.H83 1983.
Proceedings Of The 1981 KL-One Workshop. Fairchild Technical Report
No. 618. FLAIR Technical Report No. 4. May 1982. by James G. Schmolze
and Ronald J. Brachman. (8512116).
1985 ACM Thirteenth Annual Computer Science Conference March 12-14, 1985.
(8512393)
Proceedings Graphics Interface '83. Comptes Rendus Interface Graphique '83.
May 1983. Edmonton, Alberta T385.P78 1983A f.
Brinch Hansen On Pascal Compilers. by Per Branch Hansen. QA76.73.P2B75 1985.
Invitation To Database Processing. Petrocelli Books. by Leonard Gorney.
QA76.9D3G67 1985.
H. Llull
-------
∂29-Nov-85 1527 NILSSON@SU-SCORE.ARPA Patent agreement
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Nov 85 15:27:22 PST
Date: Fri 29 Nov 85 15:26:43-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Patent agreement
To: faculty@SU-SCORE.ARPA
Message-ID: <12163213398.8.NILSSON@SU-SCORE.ARPA>
I still have some questions about the new patent agreement that the
university is asking us to sign. Maybe these will be cleared up
at Tuesday's faculty lunch (maybe they won't too). Anyway, I'm
personally not signing anything yet! -Nils
-------
∂29-Nov-85 1537 LIBRARY@SU-SCORE.ARPA Paper Index To Technical Reports No Longer Available
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Nov 85 15:37:09 PST
Date: Fri 29 Nov 85 15:36:21-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Paper Index To Technical Reports No Longer Available
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12163215151.9.LIBRARY@SU-SCORE.ARPA>
We have removed the Index TO Uncataloged Materials from the reference
shelf in the Math/CS Library. This paper index was only accurate
as of January 1985. The only complete and up-to-date index to our
technical reports is the Technical Reports file in Socrates.
H. Llull
-------
∂01-Dec-85 1235 JOHNSON@SU-CSLI.ARPA My books..
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 12:34:56 PST
Date: Sun 1 Dec 85 12:23:54-PST
From: Mark Johnson <JOHNSON@SU-CSLI.ARPA>
Subject: My books..
To: folks@SU-CSLI.ARPA, linguists@SU-CSLI.ARPA
I noticed apon return that my bookcase is looking rather
bare these days..
Would anyone that has a book or journal from me please
either return it or send me mail telling me that they have
it?
Thanks,
Mark
-------
∂01-Dec-85 1639 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #41
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 16:38:56 PST
Date: 1 Dec 85 1630-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #41
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Monday, 2 Dec 1985 Volume 1 : Issue 41
Responses to PARSYM Hardware Survey:
COBWEB (King's College London)
GRIP (University College London)
----------------------------------------------------------------------
Date: Wednesday, 20 November 1985 09:32-PST
From: Paul Kelly <mcvax!kcl-cs!pkelly at seismo.CSS.GOV>
Subject: PARSYM Digest V1 #33
The Third PARSYM Survey: Computer Hardware
FROM: Paul Kelly,
Dept of Computing,
King's College London, (was Westfield College)
UK. (mail address at the end)
[Please note that there are several individuals and several
organisations involved in the project I am describing. This does not
purport to be description of the project as a whole - only my
perception of it.]
Part I (Easy)
What computer hardware are you using or developing?
We are using High Level Hardware's Orion supermicro, running Unix 4.1,
and have been using this machine's excellent user-microcode facility
although I'm not involved with that.
More interesting are our computer architecture designs. I'm
only going to talk about one - the COBWEB. An early version
is described in the Proceeding of the Nancy (1985) Conference
on Functional Programming and Computer Architecture.
COBWEB is an as-yet hypothetical machine directed at
wafer-scale integration. It is specifically directed at
functional languages. The early versions, at least, run a
machine code based on Turner's combinators augmented with
directors (see Kennaway & Sleep's paper "Director Strings as
Combinators").
What are its components (processors, memory) and how many; how do the
processors and memory communicate?
We intend there to be thousands of processing elements in a
COBWEB, although each processing element (PE) is very small.
PEs' local memory is the only storage in the machine, and
each PE's memory is quite small - perhaps only big enough for
2 - 4 reduction tokens.
PEs are arranged in a grid - possibly 6-connected, or
8-connected. We don't yet have the detailed figures to make a
choice at the moment. They communicate by passing tokens
between immediate neighbours. The early prototypes use Ivor
Catt's spiral both for fault-tolerance, and for token routing.
(the spiral starts in the middle, and grows as the end PE
passes control to its left-most working neighbour. A spiral is
created which buries faulty PEs between layers. Communication
occurs both around the spiral, and radially.)
SIMD/MIMD? Shared memory or distributed memory?
MIMD - this is a highly-parallel very small granularity
machine. Memory is distributed.
What model of concurrency are you investigating with this system?
The first design views concurrency as a parallel graph
reduction process, guaranteed to be semantically equivalent
to the standard 'normal' reduction order.
The machine interprets functional programs to give a
fully-lazy semantics. In order to extract parallelism,
strictness analysis is used during compilation to find
expressions reduceable earlier than the standard reduction
order, whilst still guaranteeing that expressions not needed
by the computation are not computed, so termination
correctness is preserved.
With directors, the graph reduction process has many
similarities with data-flow, as might be expected since
functional languages and data-flow languages are in essence
indistinguishable.
What would you like to see in your next hardware system?
No COBWEB design has yet been implemented, but we are already
looking beyond the machine described in the Nancy paper.
We are looking at different routing and fault tolerance
techniques within the grid structure, and also at more exotic
logical interconnection topologies. We are trying to stick to
fairly conservative fabrication technology - wafer-stepping
rather than direct writing of whole wafers, and self-test and
self-reconfiguration. This should keep the price down, which
I think is important. I think COBWEBs should be components of
affordable home computers, or at least cheap desk-top
workstations.
We're also looking at different evaluation mechanisms,
though we're sticking with functional languages. These
include super-combinators, or serial combinators, and
data-flow.
This seems to answer your other questions.
I must emphasize that this is a personal view.
I am Paul Kelly (Postgraduate),
King's College Dept of Computing,
Westfield College,
Kidderpore Avenue,
Hampstead,
London NW3. ('phone (01) 435 7141 ext 636)
UK.
------------------------------
Date: Thu, 21 Nov 85 10:59:47 GMT
From: Simon PJ <simonpj@ucl-cs.arpa>
Subject: GRIP
Third PARSYM survey - Computer Hardware
GRIP (Graph Reduction In Parallel) is the name of a parallel machine
designed to execute functional languages using graph reduction, under
development at University College London.
I've answered PART 1, and appended a brief writeup which gives some
more details.
Simon L Peyton Jones
Dept of Computer Science
University College London
Gower St
London WC1E 6BT
simonpj@ucl.cs (try via ISID if you have a problem)
--------------------------
Brief answers to survey
GRIP is a parallel machine designed to execute functional languages
using graph reduction. (Actually the hardware is amenable to other
languages - one group wants to put Prolog on it). It is being
developed with the support of the Alvey Directorate, in collaboration
with 3 companies.
We are developing our own hardware, consisting of microprocessor based
Processing Elements (PEs) and bit-slice Intelligent Memory Units
(IMUs).
They communicate over a bus, the IEEE P896 Futurebus. This is the
most fundamental (and maybe surprising) design decision. It allows us
to achieve substantial concurrency without using clever switches or
solving locality issues. So we can address one issue at a time -
parallel graph reduction in particular. Of course it places a limit
on the size of the machine, which we simply accept! Up to that limit
we should achieve better price/performance than more extensible
machines.
We hope that each board will contain 4 PEs and 1 IMU, and the GRIP
machine will contain a maximum of 32 boards.
GRIP is definitely MIMD! Each PE has some private memory, but the
IMUs implement a global shared structured memory (a heap, in fact).
The model of concurrency is GRAPH REDUCTION (does everyone know what
this is?).
Next system:
- migrate functionality from the PEs into the IMUs.
- rip out 4 PEs and replace with one bitslice PE
to give same or better performance with less
concurrency required.
-------------------
A brief overview of GRIP
A parallel graph reduction machine
Simon L Peyton Jones, Chris Clack and Jon Salkild
University College London
21st November 1985
GRIP is a parallel Fifth Generation machine designed to execute
functional languages using graph reduction. In this paper we
give a brief outline of graph reduction and GRIP's architecture.
1. Functional languages and graph reduction
Functional languages are Fifth Generation programming languages
which address two of the major current challenges to computer
science, namely the challenges of correctness and parallelism.
The challenge of correctness is the difficulty we experience in
writing large correct programs, a problem which Hoare eloquently
outlines in his Turing award lecture [Hoare81]. Darlington gives
an introduction to functional programming showing how some of
these problems may be alleviated [Darl84].
The organisation of a number of independent processors to co-
operate in executing a single program is the challenge of
parallelism. Functional languages contain inherent parallelism,
and so are a suitable medium in which to express parallel
programs. To understand where the parallelism comes from we will
look at a functional program:
let f x = (x+1)*(x-1)
in f 4
The "let" defines a function "f" of a single argument "x", which
computes "(x+1)*(x-1)". The program executes by evaluating "f
4", that is the function "f" applied to 4. We can think of the
!
GRIP overview
program like this:
@
/ \
f 4
where the "@" stands for function application. Applying "f" to 4
gives
*
/ \
/ \
+ -
/ \ / \
4 1 4 1
We may now execute the addition and the subtraction
simultaneously, giving
*
/ \
5 3
Finally we can exeucte the multiplication, to give the result
15
From this simple example we can see that:
(i) Executing a functional program consists of evaluating an
expression.
(ii) A functional program has a natural representation as a
tree (or more generally, a graph).
(iii) Evaluation proceeds by means of a sequence of simple
steps, called reductions. Each reduction performs a local
transformation of the graph (hence the term graph
reduction ).
(iv) Reductions may safely take place simultaneously, since
they cannot intefere with each other.
(v) Evaluation is complete when there are no further reducible
expressions.
GRIP (Graph Reduction In Parallel) is designed to execute
functional programs by performing parallel graph reduction.
Despite the opportunities for parallelism offered by functional
languages, only the ALICE project (at Imperial College) has so
far attempted a parallel implementation [Darl81]. GRIP is
intended to provide state-of-the-art performance at moderate cost
by extracting maximum performance from a fast bus. This means
that within its performance range, GRIP should provide more power
!
GRIP overview
for unit cost than more extensible designs (such as ALICE). Our
performance target for a fully populated GRIP is one million
reductions per second.
2. The GRIP architecture
Most proposals for parallel graph reduction machines look like
Figure 1. The Processing Elements (PEs) traverse the graph held
in the Intelligent Memory Units (IMUs), discovering reducible
expressions and reducing them. The principal variation between
different designs lies firstly in the the choice of
communications network, and secondly in the intelligence of the
IMUs.
-------------- -------------- --------------
| | | | | |
| Processing | | Processing | ... | Processing |
| Element | | Element | | Element |
| | | | | |
-------------- -------------- --------------
| | |
------------------------------------------------------
| Communications medium |
------------------------------------------------------
| | |
--------------- --------------- ---------------
| | | | | |
| Intelligent | | Intelligent | | Intelligent |
| Memory | | Memory | ... | Memory |
| Unit | | Unit | | Unit |
| | | | | |
--------------- --------------- ---------------
Figure 1. Physical structure of a parallel graph reduction machine
2.1 The bus
In the case of GRIP we have chosen to use a fast bus, the IEEE
P896 Futurebus, for the communications network. A bus offers an
extremely cost effective switch, but at the cost that only one
transaction can take place between a PE and an IMU at once, thus
limiting concurrency. This places a fundamental limit on the
parallelism achievable using GRIP, but it gives an extremely
cost-effective solution up to this limit. In the case of GRIP we
anticipate being able to integrate up to 120 PEs or so, on 30
boards, before running out of bus bandwidth and physical space.
The use of a bus allows us to address one research issue
(parallel reduction) at a time, rather than try to solve several
!
GRIP overview
difficult problems at once. By using a bus we therefore expect
to exploit a cost/performance/concurrency "window", and to build
a working prototype in a relatively short time (2-3 years).
2.2 The Intelligent Memory Units
GRIP's IMUs will consist of a megabyte of RAM arranged in 40-bit
words, with a fairly simple bit-slice microprogrammable processor
on the front. Instead of supporting just READ and WRITE commands
as normal memories do, the IMUs will support an instruction set
of high-level operations, chosen to support parallel graph
reduction. These operations are the unit of indivisibility
supported by GRIP (all concurrent machines must provide some
indivisible operations to assure correct synchronisation of
parallel activities). In addition the use of high-level
operations reduces the bus bandwidth required to communicate with
the IMUs.
2.3 The Processing Elements
The PEs are autonomous units responsible for performing
reductions on the graph held in the IMUs. They will be of
straightforward design, based around a microprocessor (eg
Transputer, MC68020, NS32332), and will include their own private
memory, which is inaccessible to the rest of the system.
The processor within a PE executes a program held in local
memory.
2.4 Physical arrangements
Although they are logically separate, we will integrate several
PEs and one IMU on each board plugged into the bus. This
maximises the use of our scarcest resource (bus slots), and also
maximises the number of concurrent activities in the system by
putting several on each board.
Most transactions between a PE and an IMU will be carried out on
a split cycle basis, to make the best use of scarce bus
bandwidth. The PE will write a transaction request into a fast
transaction buffer held in the bus interface section. The bus
interface will then acquire the bus (which may take some time),
send all pending requests to the corresponding buffer on the
destination board and relinquish the bus. The request will be
processed by the recipient IMU, which will write a reply
transaction into the transaction buffer. The reply will then get
transferred back to the requesting PE by the same mechanism.
Achieving an implementation of this protocol without imposing
substantial latency on transactions is one of the major hardware
challenges of the project.
!
GRIP overview
3. Project status
The GRIP project is funded by the Alvey directorate as a
collaborative project between University College London, ICL,
High Level Hardware Ltd and Research Software Ltd. Three full
time Research Assistants form the main team based at UCL, and
work began in the late Autumn of 1985.
!
GRIP overview
References
[Darl81] Darlington J and Reeve M, "ALICE - a multiprocessor
reduction machine for the parallel evaluation of
applicative languages", Proc ACM conference on
Functional Programming Languages and Computer
Architecture, New Hampshire, pp65-75, Oct 1981.
[Darl84] Darlington J, "Functional programming", in
Distributed Computing, ed Duce, Peter Peregrinus,
1984.
[Hoare81] Hoare CAR, "The Emperor's old clothes", CACM 24(2),
pp75-83, Feb 1981.
------------------------------
End of PARSYM Digest
********************
∂01-Dec-85 2336 ACUFF@SUMEX-AIM.ARPA New Explorer Software
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 23:36:37 PST
Date: Sun 1 Dec 85 23:34:40-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: New Explorer Software
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12163826515.73.ACUFF@SUMEX-AIM.ARPA>
I've been using the newest Explorer software (2.48) for several
days, and I think it's at least as stable as the 2.12 that most people
are using. Also, I've generated a few more bug fixes for it, and we
have most sources for it. Thus, I'd like everyone to start using this
new sub-version. I'll be putting it on all the pool machines soon,
and, unless I hear differently I'll put it on LOD2 on private machines
as well, if the LOD2 has 2.12 now, so if you feel you don't want to
use the new version, please let me know quickly.
With 2.48, X8 (pool machine outside of my office) will become the
SYS host, where system sources and various declarations are stored, so
you might want to avoid using it if another machine is free, since
others will be using it from the net for file access.
As a reminder, you should do (make-system 'ksl-patches :nowarn
:noconfirm :silent) in your login-init.lisp file to fix as many known
bugs as we have fixes for.
There are many new bug reports in Sumex:<LispM>exp-pre2.bugs. Just
the new ones can be found in x1:acuff;new-bugs.text. You might want
to glance through these so you know what problems have been
encountered.
Again, if you find a bug or problem with an Explorer, please let me
know.
-- Rich
-------
∂01-Dec-85 2347 ACUFF@SUMEX-AIM.ARPA Compatibility between Symbolics 36xx and TI Explorer
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 23:47:05 PST
Date: Sun 1 Dec 85 23:45:23-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Compatibility between Symbolics 36xx and TI Explorer
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12163828463.73.ACUFF@SUMEX-AIM.ARPA>
If you're porting code from a Symbolics to an Explorer, you should
take a look at Sumex:<LispM>36xx-Explorer.lisp. This file lists many
differences with suggestions about what can be done to circumvent
them, and some code that provides functionality on the Explorer. I
suggest putting (make-system '36xx-Explorer :noconfirm :silent) into
your login-init.lisp if you plan on developing on both machines.
Also, if you discover a major incompatibility not covered by
36xx-Explorer, *PLEASE* let me know.
-- Rich
-------
∂02-Dec-85 0859 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 08:59:27 PST
Date: Mon 2 Dec 85 08:51:50-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
cc: library@SU-SCORE.ARPA, maslin@SUMEX-AIM.ARPA
Message-ID: <12163927944.12.RICHARDSON@SU-SCORE.ARPA>
The topic for the CSD Lunch on Dec. 3 at 12:15 in MJH will be Stanford
Patent Agreements with two representatives from the Sponsored Projects
Office attending to answer questions.
-------
∂02-Dec-85 0947 @SU-CSLI.ARPA:admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Dec. 3, 1985
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 09:46:56 PST
Received: from ucbvax.berkeley.edu by SU-CSLI.ARPA with TCP; Mon 2 Dec 85 09:37:20-PST
Received: by ucbvax.berkeley.edu (5.31/1.7)
id AA16750; Mon, 2 Dec 85 09:44:17 PST
Received: by cogsci (5.31/5.16)
id AA29615; Mon, 2 Dec 85 09:43:33 PST
Date: Mon, 2 Dec 85 09:43:33 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8512021743.AA29615@cogsci>
To: allmsgs@cogsci.berkeley.edu, cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Dec. 3, 1985
Cc: admin@cogsci.berkeley.edu
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar - IDS 237A
Tuesday, December 3, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``An Approach to Conscious Experience''
Bernard J. Baars
Langley Porter Neuropsychiatric Institute, U.C.S.F.
Conscious experience has been widely viewed as a confusing
and ill-defined issue, and most psychologists have avoided it
until quite recently. However, there are straightforward ways
to specify reliable empirical constraints on the problem, sim-
ply by contrasting comparable pairs of events, one of which is
conscious and the other not. For example, we are typically
unconscious of highly predictable stimuli, though there is
strong evidence that such stimuli continue to be represented in
the nervous system. We are unconscious of automatized actions,
of the unattended stream in a selective attention paradigm, of
conceptual presuppositions, of the unconscious meaning of per-
ceptual and linguistic ambiguities, of lexical access, syntac-
tic rule-application, etc. In all these cases the unconscious
information continues to be represented and processed. Any
complete theory of conscious experience is bounded by, and must
ultimately account for, the entire set of such contrasts.
The empirical constraints converge on a model of the ner-
vous system as a distributed collection of specialists---
automatic, unconscious, and very efficient. Consciousness is
associated in this system with a "global workspace"---a memory
whose contents are broadcast to all the specialists. Special-
ists can complete or cooperate for access to the global
workspace, and those that succeed can recruit and control other
specialists in pursuit of their goals. Over the past seven
years this Global Workspace approach has been extended to a
number of puzzling issues, including action control and the
neurophysiological basis of consciousness.
----------------------------------------------------------------
ELSEWHERE
Peter Labudde, SESAME Group visiting scholar from EMS
Samedan/Switzerland, will speak on "Experiments for students in
everyday physics" at the SESAME Colloquium on Monday, December
2 at 4:00 p.m. in 2515 Tolman Hall, Campus.
Jim Greeno, EMST and Cognitive Science Program, will speak on
"How Problems Differ" at the Cognitive Psychology Colloquium on
Friday, December 6 at 4:00 p.m. in the Beach Room, 3105 Tolman
Hall, Campus.
----------------------------------------------------------------
∂02-Dec-85 0947 admin%cogsci@BERKELEY.EDU UCB Cognitive Science Seminar--Dec. 3, 1985
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 2 Dec 85 09:47:43 PST
Received: by ucbvax.berkeley.edu (5.31/1.7)
id AA16750; Mon, 2 Dec 85 09:44:17 PST
Received: by cogsci (5.31/5.16)
id AA29615; Mon, 2 Dec 85 09:43:33 PST
Date: Mon, 2 Dec 85 09:43:33 PST
From: admin%cogsci@BERKELEY.EDU (Cognitive Science Program)
Message-Id: <8512021743.AA29615@cogsci>
To: allmsgs@cogsci.berkeley.edu, cogsci-friends@cogsci.berkeley.edu
Subject: UCB Cognitive Science Seminar--Dec. 3, 1985
Cc: admin@cogsci.berkeley.edu
BERKELEY COGNITIVE SCIENCE PROGRAM
Fall 1985
Cognitive Science Seminar - IDS 237A
Tuesday, December 3, 11:00 - 12:30
240 Bechtel Engineering Center
Discussion: 12:30 - 1:30 in 200 Building T-4
``An Approach to Conscious Experience''
Bernard J. Baars
Langley Porter Neuropsychiatric Institute, U.C.S.F.
Conscious experience has been widely viewed as a confusing
and ill-defined issue, and most psychologists have avoided it
until quite recently. However, there are straightforward ways
to specify reliable empirical constraints on the problem, sim-
ply by contrasting comparable pairs of events, one of which is
conscious and the other not. For example, we are typically
unconscious of highly predictable stimuli, though there is
strong evidence that such stimuli continue to be represented in
the nervous system. We are unconscious of automatized actions,
of the unattended stream in a selective attention paradigm, of
conceptual presuppositions, of the unconscious meaning of per-
ceptual and linguistic ambiguities, of lexical access, syntac-
tic rule-application, etc. In all these cases the unconscious
information continues to be represented and processed. Any
complete theory of conscious experience is bounded by, and must
ultimately account for, the entire set of such contrasts.
The empirical constraints converge on a model of the ner-
vous system as a distributed collection of specialists---
automatic, unconscious, and very efficient. Consciousness is
associated in this system with a "global workspace"---a memory
whose contents are broadcast to all the specialists. Special-
ists can complete or cooperate for access to the global
workspace, and those that succeed can recruit and control other
specialists in pursuit of their goals. Over the past seven
years this Global Workspace approach has been extended to a
number of puzzling issues, including action control and the
neurophysiological basis of consciousness.
----------------------------------------------------------------
ELSEWHERE
Peter Labudde, SESAME Group visiting scholar from EMS
Samedan/Switzerland, will speak on "Experiments for students in
everyday physics" at the SESAME Colloquium on Monday, December
2 at 4:00 p.m. in 2515 Tolman Hall, Campus.
Jim Greeno, EMST and Cognitive Science Program, will speak on
"How Problems Differ" at the Cognitive Psychology Colloquium on
Friday, December 6 at 4:00 p.m. in the Beach Room, 3105 Tolman
Hall, Campus.
----------------------------------------------------------------
∂02-Dec-85 1002 BSCOTT@SU-SCORE.ARPA Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 10:02:02 PST
Date: Mon 2 Dec 85 09:51:25-PST
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: Tuesday Lunch
To: Faculty@SU-SCORE.ARPA
cc: BScott@SU-SCORE.ARPA
Message-ID: <12163938790.29.BSCOTT@SU-SCORE.ARPA>
The persons representing Sponsored Projects to discuss the patent and copy-
right issues are Clive Liston, Associate Director for Intellectual Property
Administration, his assistant, Cornelia Shonkwiler, and Phyllis Hughes, the
SPO contract officer for Computer Science.
Betty
-------
∂02-Dec-85 1015 ZEC@SU-CSLI.ARPA interactions of morphology, syntax, and discurse
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 10:15:20 PST
Date: Mon 2 Dec 85 10:04:07-PST
From: Draga Zec <ZEC@SU-CSLI.ARPA>
Subject: interactions of morphology, syntax, and discurse
To: folks@SU-CSLI.ARPA
cc: zec@SU-CSLI.ARPA
Copies of the paper by Draga Zec to be discussed in this Thursday's meeting of
the Interactions of Morphology, Syntax, and Discourse group, will be available
at the CSLI Receptionists' desk on Wednesday morning.
-------
∂02-Dec-85 1041 BSCOTT@SU-SCORE.ARPA RFP from IBM
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 10:41:35 PST
Date: Mon 2 Dec 85 10:41:17-PST
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: RFP from IBM
To: AC@SU-SCORE.ARPA
cc: BScott@SU-SCORE.ARPA
Message-ID: <12163947866.29.BSCOTT@SU-SCORE.ARPA>
Nils has received a Request for Proposal OEM DP Survey for Mobile
Environment. The statement of work includes:
1. General. This survey will identify alternative data processing systems
and architectures for performing in a mobile environment while meeting
the performance objectives established for this study. Baseline performance
and capacity for evolutionary growth are of primary interest.
2. Objectives. The objectives of this project are:
a. Identify candidate computers which achieve projected performance re-
quirements.
b. Rank the candidate computers which demonstrate the potential of meeting
performance requirements, and which demonstrate a growth capability for
future needs.
Proposals are due at IBM (Westgate Village, CA) on 12/20/85. The RFP says
the performance period is 2/3/85 - 5/30/86--but they must mean 2/3/86 -
5/30/87.
No budget dollar amount is mentioned.
If you are expecting this RFP, or if you are interested in submitting a pro-
posal, I have full information in my office.
Betty
-------
∂02-Dec-85 1106 RICHARDSON@SU-SCORE.ARPA Faculty Accomplishments
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 11:06:44 PST
Date: Mon 2 Dec 85 11:06:16-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Faculty Accomplishments
To: ac@SU-SCORE.ARPA
Message-ID: <12163952415.12.RICHARDSON@SU-SCORE.ARPA>
The "Faculty Accomplishments" which were distributed to you on 11/19/85
are due today. I will be delivering those that I receive by today to SOE
tomorrow.
Anne
-------
∂02-Dec-85 1121 EMMA@SU-CSLI.ARPA Bibtex emacs library
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 11:16:14 PST
Date: Mon 2 Dec 85 11:03:18-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Bibtex emacs library
To: folks@SU-CSLI.ARPA
Tel: 497-3479
I am looking for the source file for the bibtex emacs library (i.e., the
file bibtex.emacs) and I strongly suspect that it is somewhere at SRI, but
I can't find it. Do any of you have it?
Emma
ps. I got the compiled library from Hans Uszokoreit who, I believe, adapted
the library from the biblio library (I have the source file for that).
However, Hans is unavailable at this time (and for another week at least).
-------
∂02-Dec-85 1121 REGES@SU-SCORE.ARPA anyone free on 11/5?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 11:14:10 PST
Date: Mon 2 Dec 85 11:13:05-PST
From: Stuart Reges <REGES@SU-SCORE.ARPA>
Subject: anyone free on 11/5?
To: faculty@SU-SCORE.ARPA
Office: Margaret Jacks 210, 497-9798
Message-ID: <12163953656.49.REGES@SU-SCORE.ARPA>
I have asked several people individually, but I still seem to be without a
speaker for this Thursday's department lecture series. This is CS300, the
series intended primarily for new PhD students who are trying to find out what
kind of research is going on here. The talk is scheduled from 2:45 to 4. If
you can speak, please let me know. Otherwise I will have to cancel.
-------
∂02-Dec-85 1123 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Announcing a Logic Meeting at UCLA
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 11:22:42 PST
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 2 Dec 85 11:12:14-PST
Date: 02 Dec 85 1109 PST
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: Announcing a Logic Meeting at UCLA
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
Logic Meeting at UCLA
January 24, 25, 26 1986
There will be a very informal gathering of logicians at UCLA, starting
with lunch at 12:00 noon on Friday, January 24 and ending at noon on Sunday
January 26. As usual, there will be two talks on Friday afternoon, three
talks and a session on problems and short announcements on Saturdy, and two
more talks on Sunday morning. The entertainment will include a get together
on Friday afternoon and a party on Saturday night.
The speakers this year are M. Beeson, H. Gaifman, Ph. Kolaitis, A.
Louveau, M. Lerman, M. Magidor and J. Steel. In addition, the following
logicians have indicted that they are likely to attend: J. Barwise, C. C.
Chang, R. Dougherty, S. Feferman, M. Foreman, A. Horn, E. Kastanas, A.
Kechris, P. Maddy, D. A. Martin, W. Mitchell, J. R. Moschovakis, Y.
Moschovakis, R. Solovay and H. Woodin.
EVERYONE IS INVITED
This first announcement is being sent to a small number of persons on a
a hastily contrived mailing list, so please mention the meeting to your friends
who might be interested in coming. If you plan to come, drop me (Y.Moschovakis)
a note or call the number below.
We have reserved rooms for the meeting at the following hotels which are
quite near the Campus.
Claremont, 1044 Tiverton Ave., (213) 208 5957
Royal Palace Westwood Hotel (the old Tiverton)
Tiverton Ave., (213) 208 6677
Holiday Inn - Brentwood, 170 North Church Lane, (213) 476 6411
Bel-Air Sand Hotel, 11461 Sunset Blvd. (213) 476 6571
The first tow of these are the closest and the least expensive. Please
make your own reservations, mentioning the UCLA Logic meeting.
In accordance with the informal nature of the meeting, the lectures will
be primarily expository, and there will be plenty of time for talk.
A second and final announcement will be mailed on January 6. That wil
contain the formal program of talks, instructions for getting to UCLA, etc.,
as well as the names of all those who notify me (YM) before Christmas that
they are planning to come.
Telephones: For additional info call our secretary Elain Barth during working
hours at (213) 825 1148, or myself (YM) at home, evenings, (213) 394 5201.
Yiannis N. Moschovakis
Department of Mathematics
University of California
Los Angeles, CA 90024
math.ynm@LOCUS.UCLA.EDU
∂02-Dec-85 1205 EMMA@SU-CSLI.ARPA bibtex emacs library
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 12:05:03 PST
Date: Mon 2 Dec 85 11:48:26-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: bibtex emacs library
To: folks@SU-CSLI.ARPA
Tel: 497-3479
The file I asked for is being retrieved from archives over at SRI-AI.
Many thanks to those of you who sent in suggestions.
Emma
ps. Sorry for sending these messages to folks.
-------
∂02-Dec-85 1620 RICHARDSON@SU-SCORE.ARPA Near West Campus Invitation
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 16:20:06 PST
Date: Mon 2 Dec 85 15:45:02-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Near West Campus Invitation
To: ac@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12164003163.39.RICHARDSON@SU-SCORE.ARPA>
Recently you received a memo from Jim Gibbons inviting you to attend a
Near West Campus review of work to date on December 16 from 4-6. I just
spoke with Jane Johnston on this and she has advised me that this meeting
will take place in Durand 450. Please make a note of it.
-------
∂02-Dec-85 1716 DAVIES@SUMEX-AIM.ARPA No meeting this Wednesday
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 17:16:04 PST
Date: Mon, 2 Dec 1985 17:14 PST
Message-ID: <DAVIES.12164019531.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: No meeting this Wednesday
cc: Davies@SUMEX-AIM.ARPA
There will be no weekly (?) meeting this Wednesday, December 4.
-- Byron
∂02-Dec-85 1727 MODICA@SU-SCORE.ARPA survey forms
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 17:26:55 PST
Date: Mon 2 Dec 85 16:50:11-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: survey forms
To: instructors@SU-SCORE.ARPA
Message-ID: <12164015024.25.MODICA@SU-SCORE.ARPA>
This is a reminder to pick up survey forms from me (Gina) in MJH 030.
It is very important that the class be surveyed, so please come by for
the forms.
-Gina
-------
∂02-Dec-85 1732 MODICA@SU-SCORE.ARPA grades
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 17:31:59 PST
Date: Mon 2 Dec 85 16:57:54-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: grades
To: instructors@SU-SCORE.ARPA
Message-ID: <12164016427.25.MODICA@SU-SCORE.ARPA>
End Quarter Reports will be available in my office (MJH 030)
starting tomorrow afternoon.
Please come by to pick them up or let me know where you want
yours mailed. Please remember to specify which course you are
teaching.
Thank You.
Gina
-------
∂02-Dec-85 1802 TAJNAI@SU-SCORE.ARPA Bell Fellowship
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 18:02:02 PST
Date: Mon 2 Dec 85 18:00:15-PST
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: Bell Fellowship
To: Faculty@SU-SCORE.ARPA
Message-ID: <12164027778.17.TAJNAI@SU-SCORE.ARPA>
We have not received the "call" for nominations for the Bell
Fellowship, but we will receive it shortly. Last year the deadline
was January 15 at Bell. The nominees need at least a month to get
their packets together -- especially considering lost time over the
holidays.
Feel free to send your nominations now. I will notify you as soon
as I get the "call" and when nominations will be closed.
We want to nominate 3 first or second year PHD students.
Carolyn
-------
∂03-Dec-85 0923 @SU-CSLI.ARPA:CLT@SU-AI.ARPA Seminar in Logic and Foundations
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 09:23:21 PST
Received: from SU-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 3 Dec 85 09:17:41-PST
Date: 03 Dec 85 0909 PST
From: Carolyn Talcott <CLT@SU-AI.ARPA>
Subject: Seminar in Logic and Foundations
To: "@DIS.DIS[1,CLT]"@SU-AI.ARPA
Speaker: Ian Mason, Philosophy Dept., Stanford
Title: Proving properties of destructive LISP programs (cont'd)
Time: Friday Dec. 6, 1985, 12:00-1:00 P.M.
Place: Math. Faculty Lounge, Stanford, Room 383N.
S. Feferman
∂03-Dec-85 0923 ullman@su-aimvax.arpa CS300 talk
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 09:23:21 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 3 Dec 85 09:19:19 pst
Date: Tue, 3 Dec 85 09:19:19 pst
From: Jeff Ullman <ullman@diablo>
Subject: CS300 talk
To: mugs@sumex, nail@diablo
It appears that I will be giving a NAIL! overview at the
CS300 lecture, 2:45 PM, Thursday 12/5, in Hist. Corner 202.
∂03-Dec-85 1101 TAJNAI@SU-SCORE.ARPA Bell Fellowship
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 11:01:13 PST
Date: Tue 3 Dec 85 10:54:10-PST
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: Bell Fellowship
To: faculty@SU-SCORE.ARPA
Message-ID: <12164212357.10.TAJNAI@SU-SCORE.ARPA>
I called Bell this morning and got some details. The deadline for
applications is January 15, 1986. Therefore, the deadline for
nominations is Friday, Dec. 13.
U.S. citizens or permanent residence required.
Carolyn
-------
∂03-Dec-85 1148 LANSKY@SRI-AI.ARPA Next Monday's PLANLUNCH
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 11:48:18 PST
Date: Tue 3 Dec 85 11:44:55-PST
From: LANSKY@SRI-AI.ARPA
Subject: Next Monday's PLANLUNCH
To: planlunch.dis: ;
REASONING ABOUT CONTROL IN A HIGH-LEVEL COMPUTER VISION SYSTEM
Leonard Wesley
SRI International, AI Center
11:00 AM, MONDAY, December 9
SRI International, Building E, Room EJ228 (new conference room)
If you built an expert system, how would you expect it to decide what to
do next in complex situations? Typically there are several alternative
actions it might take to reach some goal. In some cases, the best alternative
is clear or the choices do not warrant extensive analysis. At times the
consequences of pursuing some action justify expending the effort to obtain
the necessary information to analyze the pros and cons of choosing a
particular alternative.
Most would agree that the information that is needed to reach any decision is,
to some degree, uncertain, imprecise, and occasionally inaccurate (called
"evidential" information). Clearly knowledge about the certainty, precision,
and accuracy of information can be used to improve a system's
ability to reason about (i.e., control) its actions. In this talk, we shall
describe how this might be accomplished by an expert system in the domain
of high-level computer vision. We shall explain why we view Shafer's theory
of belief functions as being better suited than some other models as a
theoretical foundation for representing evidential information and reasoning
about control. Results from a large number of image interpretation
experiments will be presented to demonstrate how a system's performance can be
improved when Shafer's theory is soundly exploited. Finally, we shall briefly
describe how our approach to control might be extended to an evidential-based
framework for planning under uncertainty.
-------
∂03-Dec-85 1203 NILSSON@SU-SCORE.ARPA Faculty Meeting
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 12:03:29 PST
Date: Tue 3 Dec 85 12:03:16-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Faculty Meeting
To: ac@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12164224937.32.NILSSON@SU-SCORE.ARPA>
Here's a tentative agenda for next Tuesday's special faculty meeting.
Please let me know if you have additional agenda items that cannot
wait until our regular meeting in January. -Nils
Tentative Agenda for December 10, 1985 General Faculty Meeting
(Special Meeting since we have a lot to talk about and ought not
to wait until regular meeting in January.)
MJH 146, 1:15 pm [NOTE earlier time--since it's a long agenda]
1. Reports
Financial, Betty Scott
(items: salary research offsets, ...)
Facilities, Lester Earnest
(items: Courtesy Computer Accts Policy, APS, Long-range Plans, ...)
PhD Program Committee Progress Report, Terry Winograd
Forum, Carolyn Tajnai
Others as may be appropriate
2. Report on Long-Range Planning Process, Nils Nilsson
3. Report on Undergraduate Major Planning
Curriculum Matters, Jeff Ullman
Summary of Curriculum approval process with UG Council and C-US, Jeff
Ullman and Nils Nilsson
Summary of discussions with Dean Gibbons regarding resources, Nils Nilsson
Discussion
4. Report on Progress on Searches, Nils Nilsson
Robotics
Systems
Possible New Searches
5. Proposed Consulting Professors (Tenenbaum and Hayes), Nils Nilsson
6. New Patent and Copyrights Policy, Betty Scott
7. Proposal on "Visiting Professorship," John McCarthy and Nils Nilsson
8. Suggestion for a Survey of CSD Graduates, Bob Floyd
Adjourn 3:45 (at the latest because we get kicked out of the room then).
-------
∂03-Dec-85 1315 MODICA@SU-SCORE.ARPA End Quarter Reports
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 13:12:53 PST
Date: Tue 3 Dec 85 13:11:12-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: End Quarter Reports
To: instructors@SU-SCORE.ARPA
Message-ID: <12164237302.24.MODICA@SU-SCORE.ARPA>
I am putting EQRs in your mailboxes this afternoon.
Also -- please please come by and pick up survey forms.
-Gina
-------
∂03-Dec-85 1915 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #42
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 19:15:08 PST
Date: 3 Dec 85 1824-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #42
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 4 Dec 1985 Volume 1 : Issue 42
Today's Topics:
Response to PARSYM Hardware Survey: CEDAR (Illinois)
SEAI Parallel Computing Survey
----------------------------------------------------------------------
Date: Fri, 29 Nov 85 12:31:36 cst
From: harrison@uicsrd.CSRD.UIUC.EDU (Luddy Harrison)
>> The Third PARSYM Survey: Computer Hardware
>>
>> Part I (Easy)
>>What computer hardware are you using or developing?
The CEDAR machine will be constructed from eight-processor multiprocessors
designed and built by Alliant computers, and modified by us. The principle
piece of hardware we are designing is the omega network which will connect
the processors to a large, interleaved shared memory. In addition, we
are designing vector prefectching boards, "processors" which sit between
each memory bank and the network (I'll describe their function later)
and possibly, but not certainly, a cache system for the global memory.
>>What are its components (processors, memory) and how many; how do the
>>processors and memory communicate?
We will double the machine size periodically. Currently,
we have 16 processors (2 Alliants); given the machine room size and
the price of the Alliant machines, ~128 is the practical maximum.
>>SIMD/MIMD? Shared memory or distributed memory?
MIMD. Well, ... Each of the eight processors in an Alliant machine
has a full complement of vector instructions, so that the machine looks
like a pure MIMD machine when the processors are in scalar mode, but
a hybrid when both inter-processor concurrency and vector concurrency
are being used. Shared memory. Each "cluster" (Alliant machine) has
a shared memory, to which the processors are connected via a crossbar.
There is a cache between each processor and its corresponding cluster
memory, which is kept coherent by hardware. In addition, there is
a large "global" memory, added by us, to which every processor is connected
via an omega network (packet switching) composed of 8x8 crossbars.
The data path of the network is 64 bits wide.
>>What model of concurrency are you investigating with this system?
?? Is MIMD a model? If so, then MIMD.
>>What would you like to see in your next hardware system?
Not currently planning a next system. (Still at work on this one!)
>> Part II (Optional, for extra credit)
>>0. Project summary:
>>What model of concurrency (e.g., dataflow, communicating sequential
>>processes, actors, futures, etc.) is your work based on? What
>>language, if any, are you using in your work?
I hope that it does not reflect an essential inelegance that I can't
come up with a model name. We have a big, fast, shared memory machine
and we will be running big, fast programs on it!
Fortran is the first language, for better or worse, to appear on
the machine. We are planning a compiler / run-time environment
for lisp. Alliant is talking about making a parallel C available,
but no specifics have come forth yet. Probably, many langauges
will be supported in the end.
>>1. Architectural classification:
>>SIMD or MIMD?
MIMD + vector instructions in each processor.
>>2. Processing elements:
>>Describe each processor in the system in terms of type (e.g., 68000
>>equivalent, Lisp machine, custom), "power" (e.g., in MIPS or relative
>>to a Vax or 68000), and memory size. If the processors are simulated
>>then also describe the uniprocessor and mechanism for simulation. If
>>the processors in the system are not of uniform type then describe
>>each type and their relationship to each other.
Each cluster has eight so-called "CE's" (computational elements), which
runs a 68020 instruction set, in addition to the vector instructions
which are sped along by some fast floating point hardware. While
the 68020 instruction set is used, the processors are not 68020s: they
are built from gate arrays, and each is roughly 2-3 times as fast as a VAX
785. There are also a number of "IP's" (interactive processors) in
each cluster, which are used primarily to handle sequential jobs, such
as editing.
>>How many processors are there in the minimum and maximum configurations?
>>How many are you currently using?
We have 16 processors (two clusters) at present. The idea is for the
machine to be easily scalable. No "new" hardware is required to
double the machine size, just more of the old. And money.
Price (and machine room size) aside, 1K+ processors are feasible.
>>3. Memory system:
>>Describe how memory is distributed and accessed in the system. Shared
>>memory or distributed memory? Is there a single address space or does
>>each processor have its own address space? What sort of caching is
>>employed, if any: snoopy, write-through, or something else? What
>>sizes are the caches?
One great big address space. Data is labeled by the compiler or
by the user as shared or private, at the processor, cluster, or global
level. There are 64Kbytes of cache between the processors of a cluster
and a cluster memory. Snoopy cache. The cache is "a complex beast,"
as one of our hardware people says.
>>What are the minimum and maximum amounts of memory? How much are you
>>currently working with?
Each module of global memory will have 8Mbytes (1Mword - 64 bit words).
There will be one module per processor. For a 32 processor machine, this
means 256Mbytes of global memory. If a 1Mbit chip becomes available
soon, the figure will quadruple. The cluster comes with up to 8Mbytes
of cluster memory; extensions to the backplane to allow more than this
are planned.
>>4. Communication system:
>>How are processors connected to each other and to memory? Describe in
>>terms of topology (e.g., tree, systolic array, pipe, grid), switching
>>type (e.g., LAN, bus, Butterfly switch), and throughput (e.g., bus
>>transmission rates, time to access memory on remote nodes, time to
>>broadcast a message to all nodes).
Each stage in the interconnection network causes a delay of 170ns;
this gives a peak bandwidth, for a 32 processor machine, of 12Gbits/s
for the interconnection network. To realize such a bandwidth, each processor
will have to keep its memory port busy by the use of lookahead buffers,
vector prefetching hardware, etc. The effects of caching and network
conflicts must also be accounted for. No numbers are available on the
effective bandwidth yet.
>>5. Synchronization:
>>What hardware mechanisms does the system supply to support
>>synchronization?
Lots and lots. At the cluster level, Alliant provides several mechanisms
for synchronization, including loop self-scheduling, and a variant of
the usual test and set instructions. The global memory network will
have, at each memory module, a simple processor which will allow a
variety of fetch/test/and op instructions to be performed on globally
shared data. These instructions are not performed, as in the combining
network of the ultracomputer, in the switches of the network, but
rather at the memory-module-side of the network. See papers by
Prof. Pen Yew (Illinois) for a description of the various instructions
so implemented.
>>6. Pragmatics
>>Is your system geared towards either specific programming languages or
>>applications?
At present, the system is used almost exclusively by numerical analysts.
But there is hope. As I've mentioned, we are planning to implement lisp
on the system.
>>Is the hardware of your system generally available or, if custom-made,
>>likely to be available in future?
Alliant machines are generally available. The modifications to the machine
for the purposes of building CEDAR, as well as the global network boards
and gate arrays, are, as yet, not generally available.
>>If you're now using a multiprocessor system, how does the architecture
>>of your development system correspond to your research target
>>architecture?
Very closely. Some differences have occurred because the Alliant
machines were not designed to be themselves the components of a larger
machine.
>>What are the advantages of your hardware setup, particularly for the
>>problems you are investigating? What are the disadvantages? Is there
>>a system that would better meet your needs?
The biggest advantage is that someone else designed and built the
processors; this is the usual situation when composing a machine
of microprocessors, but it is even more appreciable when the processors
are themselves high performance machines. It means that we can concentrate
on the central problem of the design, namely, the global memory and
omega network. This principle advantage is also the principle disadvantage:
we must incorporate our design into an existing architecture, which, I
am told by those doing the hardware design, can be a painful process.
>>------------------------------
-Luddy Harrison
Center for Supercomputer Research and Development
302D Talbot Laboratory
104 South Wright Street
Urbana IL 61801-2932
(217) 333 4168
------------------------------
Date: Tue, 3 Dec 1985 18:01 PST
From: DAVIES@SUMEX-AIM.ARPA
Subject: SEAI Parallel Computing Survey
An advertising blurb showed up in the mail that PARSYM readers may
find interesting. I include the text for informational purposes, not
as an advertisement, though I have included pointers for those who
want to check further. I have no connection with SEAI Technical
Publications.
If anyone has seen the report itself, please pass along your opinions
to PARSYM. -- BD
----------------
Parallel Processing: The Technology of Fifth Generation Computers
Publication Date: September 1985
Project Manger: Richard K. Miller
ISBN: 0-89671-067-X
Price: $525
Preface: A new era in computing is beginning in which very
high-performance systems will be dominated by parallel architectural
systems. The high cost of today's supercomputers prevent their use
for all but the most important problems, and the traditional von
Neumann computer architecture has been pushed to its limits.
Computers with parallel architectures have already been commercially
introduced. These machines will provide advanced capabilities for
users in areas such as artificial intelligence, signal processing,
engineering/scientific simulation, and voice recognition.
Content: The report explains the workings of several SIMD, MIMD, and
dataflow architectures in non-theoretical terminology. The impact of
parallel processing computers on business, industry, national defense,
science, engineering, and the quality of life is examined. The
parallel processing projects and products of 35 international research
groups and 19 leading corporations are presented. A survey of experts
in the field explores opinions and forecasts on general architecture,
problem solving strategies, and applications. Views of experts in the
United States, Japan, and Europe are compared. The international
markets for parallel processing computers are examined for 1986, 1988,
and 1990.
Intended audience: Engineers and scientists applying simulation,
modeling, and advanced problem solving with an interest in using
leading edge computatational tools; professionals applying artificial
intelligence technologies who are interested in next-generation
hardware; strategic planners involved in electronics, computer and
semiconductor businesses.
Contents
Executive Summary
1 - Introduction
2 - The need for a new generation of computing
2.1 The emergence of AI
2.2 Limitations in vision technology
2.3 Limitations in speech recognition
2.4 Limitations in natural language understanding
2.5 Limitations in expert systems
2.6 Limitations in supercomputers
3 - The technology of parallel procesing
3.1 The von Neumann bottleneck
3.2 Exploring new architectures
3.3 What is parallel processing?
3.4 SIMD architectures
3.5 Pipeline processing
3.6 MIMD architectures and dataflow
3.7 Examples of parallel architectural design
3.7.1 CEDAR at the University of Illinois
3.7.2 PASM at Purdue University
3.7.3 The Columbia Non-Von Machine
3.8 Pioneer commercial parallel machines
3.8.1 Parallelism in supercomputers
3.8.2 Commercial massively parallel machines
3.8.3 Governmental support of parallel processing
3.9 Research in Japan
3.9.1 The Fifth Generation Research Project
3.9.2 National Superspeed Computer Project
3.10 The MCC Advanced Generation Computer
3.11 How much parallelism
3.12 Applications for parallel processing
3.13 Specialized machines
3.14 Signal processing
3.15 Symbolic processing
3.16 Multifunction machines
4 - A new breed of software
4.1 Software for AI
4.2 Software for the non-von Neumann environment
4.3 LISP vs. Prolog
4.4 New languages for parallel processing
4.5 Restructuring existing Fortran programs
4.6 Software developement: an iterative process
4.7 Task dedicated software
4.8 Automatic programming
5 - The impact of Fifth Generation computers
5.1 A new breed of computers
5.2 What will Fifth Generation computers do?
5.3 User interfaces
5.4 A potential shift in world economics
5.5 The critical importance of parallel computing
5.6 Impact on business and office management
5.7 Impact on factory automation
5.8 Impact on national defense
5.9 Impact on science and engineering
5.10 Impact on the quality of life
5.11 Summary
6 - Research groups to watch
6.1 The Alvey Directorate
6.2 Argonne National Laboratory
6.3 California Institute of Technology
6.4 Carnegie-Mellon University
6.5 The Centre de Recherche Information de Montreal
6.6 Columbia University
6.7 Electrotechnical Laboratory
6.8 ESPRIT
6.9 University of Illinois
6.10 Institute for New Generation Computer Technology
6.11 Lawrence Livermore Laboratory
6.12 Los Alamos National Laboratory
6.13 University of Manchester
6.14 Massachusetts Institute of Technology
6.15 University of Michigan
6.16 Microelectronics and Computer Technology Corp.
6.17 University of Minnesota
6.18 National Security Agency
6.19 New York University
6.20 University of North Carolina
6.21 North Carolina State University
6.22 Purdue University
6.23 University of Reading
6.24 Semiconductor Research Corporation
6.25 Simon Fraser/Queen's University
6.26 Stanford University
6.27 System Development Foundation
6.28 Technical University of Berlin
6.29 University of Texas at Austin
6.30 The University of Toronto
6.31 University of Utah
6.32 U. S. Department of Defense
6.33 University of Washington
6.34 University of Waterloo
6.35 Yale University
7 - Companies to watch
7.1 Alliant Computer Systems Corporation
7.2 Automatix, Inc.
7.3 Bolt Beranek and Newman, Inc.
7.4 Control Data Corporation
7.5 Cray Research, Inc.
7.6 Denelcor, Inc.
7.7 Digital Equipment Corporation
7.8 Eastman Kodak
7.9 ELXSI
7.10 Encore Computer Corporation
7.11 ETA Systems
7.12 Floating Point Systems, Inc.
7.13 General Electric
7.14 Goodyear Aerospace
7.15 IBM
7.16 Intel Scientific Computers
7.17 Kurzweil Applied Intelligence
7.18 Schlumberger
7.19 Thinking Machines Corporation
8 - Delphi survey
8.1 General architecture
8.2 Connections
8.3 Memory
8.4 Problem solving
8.5 Programming languages
8.6 Applications
8.7 Processing limit for AI applications
8.8 Comparison: United States, Japan, Europe
8.9 Summary
9 - Market forecast
9.1 Artificial intelligence potential market
9.2 Scientific and engineering potential market
9.3 Market forecast: United States
9.4 Market forecast: Japan
9.5 Market forecast: Europe
9.6 International market leadership
9.7 Summary
10 - For further reading
10.1 Advanced generation computing periodicals
10.2 Books
10.3 Conference proceedings
10.4 Technical papers and articles
(For information call (404) 342-9638 or write to:
SEAI Technical Publications
P.O. Box 590
Madison, GA 30650)
------------------------------
End of PARSYM Digest
********************
∂03-Dec-85 1934 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #42
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 19:34:38 PST
Date: 3 Dec 85 1824-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #42
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Wednesday, 4 Dec 1985 Volume 1 : Issue 42
Today's Topics:
Response to PARSYM Hardware Survey: CEDAR (Illinois)
SEAI Parallel Computing Survey
----------------------------------------------------------------------
Date: Fri, 29 Nov 85 12:31:36 cst
From: harrison@uicsrd.CSRD.UIUC.EDU (Luddy Harrison)
>> The Third PARSYM Survey: Computer Hardware
>>
>> Part I (Easy)
>>What computer hardware are you using or developing?
The CEDAR machine will be constructed from eight-processor multiprocessors
designed and built by Alliant computers, and modified by us. The principle
piece of hardware we are designing is the omega network which will connect
the processors to a large, interleaved shared memory. In addition, we
are designing vector prefectching boards, "processors" which sit between
each memory bank and the network (I'll describe their function later)
and possibly, but not certainly, a cache system for the global memory.
>>What are its components (processors, memory) and how many; how do the
>>processors and memory communicate?
We will double the machine size periodically. Currently,
we have 16 processors (2 Alliants); given the machine room size and
the price of the Alliant machines, ~128 is the practical maximum.
>>SIMD/MIMD? Shared memory or distributed memory?
MIMD. Well, ... Each of the eight processors in an Alliant machine
has a full complement of vector instructions, so that the machine looks
like a pure MIMD machine when the processors are in scalar mode, but
a hybrid when both inter-processor concurrency and vector concurrency
are being used. Shared memory. Each "cluster" (Alliant machine) has
a shared memory, to which the processors are connected via a crossbar.
There is a cache between each processor and its corresponding cluster
memory, which is kept coherent by hardware. In addition, there is
a large "global" memory, added by us, to which every processor is connected
via an omega network (packet switching) composed of 8x8 crossbars.
The data path of the network is 64 bits wide.
>>What model of concurrency are you investigating with this system?
?? Is MIMD a model? If so, then MIMD.
>>What would you like to see in your next hardware system?
Not currently planning a next system. (Still at work on this one!)
>> Part II (Optional, for extra credit)
>>0. Project summary:
>>What model of concurrency (e.g., dataflow, communicating sequential
>>processes, actors, futures, etc.) is your work based on? What
>>language, if any, are you using in your work?
I hope that it does not reflect an essential inelegance that I can't
come up with a model name. We have a big, fast, shared memory machine
and we will be running big, fast programs on it!
Fortran is the first language, for better or worse, to appear on
the machine. We are planning a compiler / run-time environment
for lisp. Alliant is talking about making a parallel C available,
but no specifics have come forth yet. Probably, many langauges
will be supported in the end.
>>1. Architectural classification:
>>SIMD or MIMD?
MIMD + vector instructions in each processor.
>>2. Processing elements:
>>Describe each processor in the system in terms of type (e.g., 68000
>>equivalent, Lisp machine, custom), "power" (e.g., in MIPS or relative
>>to a Vax or 68000), and memory size. If the processors are simulated
>>then also describe the uniprocessor and mechanism for simulation. If
>>the processors in the system are not of uniform type then describe
>>each type and their relationship to each other.
Each cluster has eight so-called "CE's" (computational elements), which
runs a 68020 instruction set, in addition to the vector instructions
which are sped along by some fast floating point hardware. While
the 68020 instruction set is used, the processors are not 68020s: they
are built from gate arrays, and each is roughly 2-3 times as fast as a VAX
785. There are also a number of "IP's" (interactive processors) in
each cluster, which are used primarily to handle sequential jobs, such
as editing.
>>How many processors are there in the minimum and maximum configurations?
>>How many are you currently using?
We have 16 processors (two clusters) at present. The idea is for the
machine to be easily scalable. No "new" hardware is required to
double the machine size, just more of the old. And money.
Price (and machine room size) aside, 1K+ processors are feasible.
>>3. Memory system:
>>Describe how memory is distributed and accessed in the system. Shared
>>memory or distributed memory? Is there a single address space or does
>>each processor have its own address space? What sort of caching is
>>employed, if any: snoopy, write-through, or something else? What
>>sizes are the caches?
One great big address space. Data is labeled by the compiler or
by the user as shared or private, at the processor, cluster, or global
level. There are 64Kbytes of cache between the processors of a cluster
and a cluster memory. Snoopy cache. The cache is "a complex beast,"
as one of our hardware people says.
>>What are the minimum and maximum amounts of memory? How much are you
>>currently working with?
Each module of global memory will have 8Mbytes (1Mword - 64 bit words).
There will be one module per processor. For a 32 processor machine, this
means 256Mbytes of global memory. If a 1Mbit chip becomes available
soon, the figure will quadruple. The cluster comes with up to 8Mbytes
of cluster memory; extensions to the backplane to allow more than this
are planned.
>>4. Communication system:
>>How are processors connected to each other and to memory? Describe in
>>terms of topology (e.g., tree, systolic array, pipe, grid), switching
>>type (e.g., LAN, bus, Butterfly switch), and throughput (e.g., bus
>>transmission rates, time to access memory on remote nodes, time to
>>broadcast a message to all nodes).
Each stage in the interconnection network causes a delay of 170ns;
this gives a peak bandwidth, for a 32 processor machine, of 12Gbits/s
for the interconnection network. To realize such a bandwidth, each processor
will have to keep its memory port busy by the use of lookahead buffers,
vector prefetching hardware, etc. The effects of caching and network
conflicts must also be accounted for. No numbers are available on the
effective bandwidth yet.
>>5. Synchronization:
>>What hardware mechanisms does the system supply to support
>>synchronization?
Lots and lots. At the cluster level, Alliant provides several mechanisms
for synchronization, including loop self-scheduling, and a variant of
the usual test and set instructions. The global memory network will
have, at each memory module, a simple processor which will allow a
variety of fetch/test/and op instructions to be performed on globally
shared data. These instructions are not performed, as in the combining
network of the ultracomputer, in the switches of the network, but
rather at the memory-module-side of the network. See papers by
Prof. Pen Yew (Illinois) for a description of the various instructions
so implemented.
>>6. Pragmatics
>>Is your system geared towards either specific programming languages or
>>applications?
At present, the system is used almost exclusively by numerical analysts.
But there is hope. As I've mentioned, we are planning to implement lisp
on the system.
>>Is the hardware of your system generally available or, if custom-made,
>>likely to be available in future?
Alliant machines are generally available. The modifications to the machine
for the purposes of building CEDAR, as well as the global network boards
and gate arrays, are, as yet, not generally available.
>>If you're now using a multiprocessor system, how does the architecture
>>of your development system correspond to your research target
>>architecture?
Very closely. Some differences have occurred because the Alliant
machines were not designed to be themselves the components of a larger
machine.
>>What are the advantages of your hardware setup, particularly for the
>>problems you are investigating? What are the disadvantages? Is there
>>a system that would better meet your needs?
The biggest advantage is that someone else designed and built the
processors; this is the usual situation when composing a machine
of microprocessors, but it is even more appreciable when the processors
are themselves high performance machines. It means that we can concentrate
on the central problem of the design, namely, the global memory and
omega network. This principle advantage is also the principle disadvantage:
we must incorporate our design into an existing architecture, which, I
am told by those doing the hardware design, can be a painful process.
>>------------------------------
-Luddy Harrison
Center for Supercomputer Research and Development
302D Talbot Laboratory
104 South Wright Street
Urbana IL 61801-2932
(217) 333 4168
------------------------------
Date: Tue, 3 Dec 1985 18:01 PST
From: DAVIES@SUMEX-AIM.ARPA
Subject: SEAI Parallel Computing Survey
An advertising blurb showed up in the mail that PARSYM readers may
find interesting. I include the text for informational purposes, not
as an advertisement, though I have included pointers for those who
want to check further. I have no connection with SEAI Technical
Publications.
If anyone has seen the report itself, please pass along your opinions
to PARSYM. -- BD
----------------
Parallel Processing: The Technology of Fifth Generation Computers
Publication Date: September 1985
Project Manger: Richard K. Miller
ISBN: 0-89671-067-X
Price: $525
Preface: A new era in computing is beginning in which very
high-performance systems will be dominated by parallel architectural
systems. The high cost of today's supercomputers prevent their use
for all but the most important problems, and the traditional von
Neumann computer architecture has been pushed to its limits.
Computers with parallel architectures have already been commercially
introduced. These machines will provide advanced capabilities for
users in areas such as artificial intelligence, signal processing,
engineering/scientific simulation, and voice recognition.
Content: The report explains the workings of several SIMD, MIMD, and
dataflow architectures in non-theoretical terminology. The impact of
parallel processing computers on business, industry, national defense,
science, engineering, and the quality of life is examined. The
parallel processing projects and products of 35 international research
groups and 19 leading corporations are presented. A survey of experts
in the field explores opinions and forecasts on general architecture,
problem solving strategies, and applications. Views of experts in the
United States, Japan, and Europe are compared. The international
markets for parallel processing computers are examined for 1986, 1988,
and 1990.
Intended audience: Engineers and scientists applying simulation,
modeling, and advanced problem solving with an interest in using
leading edge computatational tools; professionals applying artificial
intelligence technologies who are interested in next-generation
hardware; strategic planners involved in electronics, computer and
semiconductor businesses.
Contents
Executive Summary
1 - Introduction
2 - The need for a new generation of computing
2.1 The emergence of AI
2.2 Limitations in vision technology
2.3 Limitations in speech recognition
2.4 Limitations in natural language understanding
2.5 Limitations in expert systems
2.6 Limitations in supercomputers
3 - The technology of parallel procesing
3.1 The von Neumann bottleneck
3.2 Exploring new architectures
3.3 What is parallel processing?
3.4 SIMD architectures
3.5 Pipeline processing
3.6 MIMD architectures and dataflow
3.7 Examples of parallel architectural design
3.7.1 CEDAR at the University of Illinois
3.7.2 PASM at Purdue University
3.7.3 The Columbia Non-Von Machine
3.8 Pioneer commercial parallel machines
3.8.1 Parallelism in supercomputers
3.8.2 Commercial massively parallel machines
3.8.3 Governmental support of parallel processing
3.9 Research in Japan
3.9.1 The Fifth Generation Research Project
3.9.2 National Superspeed Computer Project
3.10 The MCC Advanced Generation Computer
3.11 How much parallelism
3.12 Applications for parallel processing
3.13 Specialized machines
3.14 Signal processing
3.15 Symbolic processing
3.16 Multifunction machines
4 - A new breed of software
4.1 Software for AI
4.2 Software for the non-von Neumann environment
4.3 LISP vs. Prolog
4.4 New languages for parallel processing
4.5 Restructuring existing Fortran programs
4.6 Software developement: an iterative process
4.7 Task dedicated software
4.8 Automatic programming
5 - The impact of Fifth Generation computers
5.1 A new breed of computers
5.2 What will Fifth Generation computers do?
5.3 User interfaces
5.4 A potential shift in world economics
5.5 The critical importance of parallel computing
5.6 Impact on business and office management
5.7 Impact on factory automation
5.8 Impact on national defense
5.9 Impact on science and engineering
5.10 Impact on the quality of life
5.11 Summary
6 - Research groups to watch
6.1 The Alvey Directorate
6.2 Argonne National Laboratory
6.3 California Institute of Technology
6.4 Carnegie-Mellon University
6.5 The Centre de Recherche Information de Montreal
6.6 Columbia University
6.7 Electrotechnical Laboratory
6.8 ESPRIT
6.9 University of Illinois
6.10 Institute for New Generation Computer Technology
6.11 Lawrence Livermore Laboratory
6.12 Los Alamos National Laboratory
6.13 University of Manchester
6.14 Massachusetts Institute of Technology
6.15 University of Michigan
6.16 Microelectronics and Computer Technology Corp.
6.17 University of Minnesota
6.18 National Security Agency
6.19 New York University
6.20 University of North Carolina
6.21 North Carolina State University
6.22 Purdue University
6.23 University of Reading
6.24 Semiconductor Research Corporation
6.25 Simon Fraser/Queen's University
6.26 Stanford University
6.27 System Development Foundation
6.28 Technical University of Berlin
6.29 University of Texas at Austin
6.30 The University of Toronto
6.31 University of Utah
6.32 U. S. Department of Defense
6.33 University of Washington
6.34 University of Waterloo
6.35 Yale University
7 - Companies to watch
7.1 Alliant Computer Systems Corporation
7.2 Automatix, Inc.
7.3 Bolt Beranek and Newman, Inc.
7.4 Control Data Corporation
7.5 Cray Research, Inc.
7.6 Denelcor, Inc.
7.7 Digital Equipment Corporation
7.8 Eastman Kodak
7.9 ELXSI
7.10 Encore Computer Corporation
7.11 ETA Systems
7.12 Floating Point Systems, Inc.
7.13 General Electric
7.14 Goodyear Aerospace
7.15 IBM
7.16 Intel Scientific Computers
7.17 Kurzweil Applied Intelligence
7.18 Schlumberger
7.19 Thinking Machines Corporation
8 - Delphi survey
8.1 General architecture
8.2 Connections
8.3 Memory
8.4 Problem solving
8.5 Programming languages
8.6 Applications
8.7 Processing limit for AI applications
8.8 Comparison: United States, Japan, Europe
8.9 Summary
9 - Market forecast
9.1 Artificial intelligence potential market
9.2 Scientific and engineering potential market
9.3 Market forecast: United States
9.4 Market forecast: Japan
9.5 Market forecast: Europe
9.6 International market leadership
9.7 Summary
10 - For further reading
10.1 Advanced generation computing periodicals
10.2 Books
10.3 Conference proceedings
10.4 Technical papers and articles
(For information call (404) 342-9638 or write to:
SEAI Technical Publications
P.O. Box 590
Madison, GA 30650)
------------------------------
End of PARSYM Digest
********************
∂03-Dec-85 2038 BRESNAN@SU-CSLI.ARPA interactions of morphology, syntax, and discourse
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 20:38:15 PST
Date: Tue 3 Dec 85 20:33:41-PST
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: interactions of morphology, syntax, and discourse
To: folks@SU-CSLI.ARPA
26-Nov-85 22:20:05-PST,2835;000000000001
Mail-From: BRESNAN created at 26-Nov-85 22:19:29
Date: Tue 26 Nov 85 22:19:29-PST
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
This Thursday, December 5, Draga Zec will present her work on
Obligatory Control in Clausal Complements in the CSLI conference
room at 10:00 a.m. She derives the phenomenon of obligatory
anaphoric control from the theory of obviation together with the
semantics of control verbs. Serbo-Croatian, from which much of
her evidence is drawn, beautifully illuminates the two separate
factors in obligatory control, which are obscured in English.
Everyone interested in the syntax and semantics of control
constructions and their implications for linguistic theory is
invited. Written copies of the paper will be available on
Wednesday morning at the CSLI Receptionists' desk.
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
``Obligatory Control in Clausal Complements''
It is generally held that obligatory control correlates with
the non-finiteness of the complement. Both syntactic and
semantic theories of control have crucially depended on this
particular assumption. My intention is to present a case of
obligatory control into clausal complements, develop an
analysis within the LFG framework, and then explore the
implications of this case for an adequate treatment of
control.
Serbo-Croatian has two types of clausal complements, Type 1
which is generally uncontrolled, and Type 2 which allows
obligatory control with predicates like 'try', 'intend',
'persuade', 'force', etc. It will be shown that Type 2
complements cannot be dealt with in terms of the LFG theory
of functional control, or any other syntactic theory of
control. Rather, it will be argued that these complements
are a clear case of what in LFG is referred to as anaphoric
control. Certain differences in anaphoric binding properties
between the two complement types are attributed to the
phenomenon of obviation which is found with Type 2 but not
with Type 1 complements.
Since anaphoric control cannot capture the systematic
controller/controllee relation characteristic of obligatory
control, one will have to make reference to the semantic or
more precisely, thematic properties of control-inducing
predicates. This may have implications for syntactic
theories of obligatory control, whose aim is to make
predictions about controller/controllee relations solely in
syntactic terms. This case will also be relevant for the
semantic analyses that account for control solely in terms
of entailment. --Draga Zec
-------
-------
-------
∂04-Dec-85 0735 PATASHNIK@SU-SUSHI.ARPA next AFLBs
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 07:35:04 PST
Date: Wed 4 Dec 85 06:47:45-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: next AFLBs
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12164429642.9.PATASHNIK@SU-SUSHI.ARPA>
These are the last two AFLB talks this quarter:
***********************************
5-Dec-85 : John Cannon (University of Sydney)
Finding the order of a permutation group of degree 10,000
An important goal in computational group theory is the development of
fast algorithms for determining the abstract structure (composition
factors) of a finite group. This goal is now within our reach in the
case of permutation groups having degree less than 10,000. Let G be a
permutation group acting on the finite set Omega. A base for G is a
sequence B = {B←1, ..., B←k} of points from Omega, such that the identity
is the only element of G that fixes B pointwise. Let G↑(i) denote the
stabilizer G←{B←1 ... B←i}. A base for G defines the chain
G = G↑(0) > G↑(1) > ... > G↑(k) = <1>.
A strong generating set S for G, relative to the base B, is a set of
elements which contains generators for each subgroup in the above
chain. The construction of a base and strong generating set (BSCS) is
the first step in any investigation of the structure of G. In
particular, knowledge of a BSCS enables us to read off the order of G.
In this talk I shall review the Sims-Schreier algorithm for computing
a BSCS. I shall then describe the more powerful Todd-Coxeter-Schreier
algorithm. Recent studies at Sydney have demonstrated that the latter
algorithm is very unstable. As a consequence, Sims and I have
undertaken the development of a new algorithm which is based on ideas
used in the construction of very large sporadic simple groups. The
new algorithm will be described and I shall present some information
about the performance of a first implementation of this algorithm.
***** Time and place: December 5, 12:30 pm in MJ352 (Bldg. 460) ******
12-Dec-85 : Joan Hutchinson (MSRI)
Recent developements in topological graph theory
(Approximate title; official title and abstract, forthcoming)
***** Time and place: December 12, 12:30 pm in MJ352 (Bldg. 460) ******
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352. If you
have a topic you'd like to talk about please let me know. (Electronic
mail: patashnik@su-sushi.arpa, phone: (415) 497-1787). Contributions
are wanted and welcome. Not all time slots for this academic year
have been filled. The file [SUSHI]<patashnik.aflb>aflb.bboard contains
more information about future and past AFLB meetings and topics.
--Oren Patashnik
-------
∂04-Dec-85 0919 ullman@su-aimvax.arpa meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 09:19:30 PST
Received: by su-aimvax.arpa with Sendmail; Wed, 4 Dec 85 09:17:11 pst
Date: Wed, 4 Dec 85 09:17:11 pst
From: Jeff Ullman <ullman@diablo>
Subject: meeting
To: nail@diablo
Today, i think I'll cover the (small) ideas about P, NC, and
polynomial fringes that I didn't get to last week.
Meet at 11AM?
∂04-Dec-85 0949 @SU-SCORE.ARPA:MCCALL@SU-SUSHI.ARPA Announcing: CS523 - Survey of Artificial Intelligence
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 09:48:44 PST
Received: from SU-SUSHI.ARPA by SU-SCORE.ARPA with TCP; Wed 4 Dec 85 09:46:08-PST
Date: Wed 4 Dec 85 09:45:51-PST
From: Kim McCall <MCCALL@SU-SUSHI.ARPA>
Subject: Announcing: CS523 - Survey of Artificial Intelligence
To: csd@SU-SCORE.ARPA
Message-ID: <12164462065.20.MCCALL@SU-SUSHI.ARPA>
!!! ANNOUNCING !!!
CS523 - An Intensive Survey of Artificial Intelligence
(acutal title: Readings in Artificial Intelligence)
Under the sponsorship of Prof. Bruce Buchannan, we once again
present the ever popular "AI Qual Prep Seminar". In this class
we will read and discuss sections of several of the main AI
reference texts as well as a fair proportion of the seminal and
most influential papers in the field.
The primary purpose of the course is to prepare PhD candidates
for the rigors of the AI qual, but other hardy souls are also
invited to join.
The anticipated format for the course includes two one-hour
discussion sessions and one one-hour invited lecture per week.
The primary formal responsibility of class members will be to
take turns leading or recording and publishing our discussions.
The formal workload is, thus, fairly low, but the reading load
is very high.
We will benefit greatly from the efforts of last year's seminar
leader, Devika Subramanian, who has done yeowoman's service in
preparing both an excellent annotated reading list for the course
and a well-edited compilation of notes on last year's discussions.
Due to the length of the quarter, the study of AI will be seen to
fall neatly into 10 distinct areas. We expect to cover the following
topics:
Week 1: Introduction to AI
Week 2: Search and Heuristics
Week 3: Knowledge Representation
Week 4: Planning, Problem Solving, and Automatic Programming
Week 5: Deduction, Inference, and Theorem Proving
Week 6: Expert Systems
Week 7: Learning
Week 8: Natural Language Understanding
Week 9: Vision and Robotics
Week 10: Advanced Topics
including: advanced reasoning techniques
software architectures
hardware architectures
philosophical issues
future directions
The main problem now is: When shall we meet?
Three ways to decide:
(a) Fiat
(b) Take a survey now and try to decide before next quarter
(c) Take a survey now of when we could get together at the
beginning of next quarter to decide the time.
Choice (a) is terrible. If you are interested in this course,
please:
Reply to this message (or some other how get a message to this
year's TA, Kim McCall <McCall@Sushi>) to say:
(1) how great the chances are that you will want to take the
course
(2) whether or not you ever plan to take the AI qual
(3) whether you know when you will be free for the class next
quarter
(3a) if so, when
(4) when you could make a planning meeting on Monday January 6
or Tuesday January 7
Thank you.
Any Q's?
Send in those cards before it's too late.
Kim
-------
∂04-Dec-85 1037 DALRYMPLE@SU-CSLI.ARPA fun on Friday
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 10:36:28 PST
Date: Wed 4 Dec 85 10:26:52-PST
From: Mary Dalrymple <DALRYMPLE@SU-CSLI.ARPA>
Subject: fun on Friday
To: folks@SU-CSLI.ARPA, linguists@SU-CSLI.ARPA
Don't miss the last Linguistics Soiree of the semester, this Friday
at 4:45 in the Greenberg Room.
-------
∂04-Dec-85 1320 MODICA@SU-SCORE.ARPA Grade Sheets
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 13:20:30 PST
Date: Wed 4 Dec 85 13:16:38-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: Grade Sheets
To: instructors@SU-SCORE.ARPA
cc: su-bboard@SU-SCORE.ARPA
Message-ID: <12164500436.11.MODICA@SU-SCORE.ARPA>
This is reminder that ALL grade sheets (also known as End Quarter Reports)
should be brought to me (Gina, MJH 0303), NOT VICTORIA.
I know you've all grown very attached to Victoria, and that her office
is very conveniently located, but she is no longer the person handling
grades, so please don't take them to her any more.
Thank You.
-Gina
-------
∂04-Dec-85 1341 CAROL@SU-CSLI.ARPA Parking man
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 13:37:41 PST
Date: Wed 4 Dec 85 13:32:41-PST
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: Parking man
To: folks@SU-CSLI.ARPA
is out there giving tix
-------
∂04-Dec-85 1702 EMMA@SU-CSLI.ARPA Newsletter December 5, No. 4
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 17:02:28 PST
Date: Wed 4 Dec 85 16:30:33-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter December 5, No. 4
To: friends@SU-CSLI.ARPA
Tel: 497-3479
!
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
December 5, 1985 Stanford Vol. 3, No. 4
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, December 5, 1985
12 noon TINLunch
Ventura Hall A Humanistic Rationale for Technical Writing
Conference Room by Carolyn R. Miller
Discussion led by Geoff Nunberg (Nunberg@csli)
(Abstract on page 2)
3:30 p.m. Tea
Ventura Hall
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, December 12, 1985
12 noon TINLunch
Ventura Hall Title to be announced
Conference Room by Werner Frey and Hans Kamp
Discussion led by Werner Frey
(Abstract will appear next week)
2:15 p.m. CSLI Seminar
No seminar this week
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Title to be announced
Lynn Bloom
←←←←←←←←←←←←
ANNOUNCEMENT
Please note that the seminar and colloquium are no longer in Redwood
Hall room G-19. The new room will be announced in next week's
newsletter.
!
Page 2 CSLI Newsletter December 5, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
THIS WEEK'S TINLUNCH
A Humanistic Rationale for Technical Writing
by Carolyn R. Miller
Discussion led by Geoff Nunberg
This paper is typical of a number of recent articles by
sociologists, rhetoricians, and humanistically-trained writing
specialists, that insist that scientific writing is no less
rhetorical in its means and effects than is writing of an explicitly
belletristic sort. Whether or not we find their arguments compelling,
these articles raise interesting questions for producers and consumers
of technical prose, especially in intellectually self-conscious
disciplines like philosophy, AI, and linguistics. For example: What is
the common understanding of the research enterprise that underlies the
linguistic conventions characteristic of scientific prose, such as the
avoidance of ``I'' and the unusual uses of ``we'', the frequent use of
impersonal constructions, the numbering of paragraphs, and so on? Can
we apply the apparatus of traditional rhetoric to the evaluation of
the expository usefulness of particular formal languages and
notational conventions? Is there grounds for distinguishing between a
``rhetoric of information'', concerned with the selection and
arrangement of factual observations, and a ``rhetoric of description,''
concerned with the linguistic means used to report such observations?
----------
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
Obligatory Control in Clausal Complements
Draga Zec (Zec@csli)
Thursday, December 5, 10:00, Ventura Conference Room
It is generally held that obligatory control correlates with the
non-finiteness of the complement. Both syntactic and semantic theories
of control have crucially depended on this particular assumption. My
intention is to present a case of obligatory control into clausal
complements, develop an analysis within the LFG framework, and then
explore the implications of this case for an adequate treatment of control.
Serbo-Croatian has two types of clausal complements, Type 1 which
is generally uncontrolled, and Type 2 which allows obligatory control
with predicates like `try', `intend', `persuade', `force', etc. It
will be shown that Type 2 complements cannot be dealt with in terms of
the LFG theory of functional control, or any other syntactic theory of
control. Rather, it will be argued that these complements are a clear
case of what in LFG is referred to as anaphoric control. Certain
differences in anaphoric binding properties between the two complement
types are attributed to the phenomenon of obviation which is found
with Type 2 but not with Type 1 complements.
Since anaphoric control cannot capture the systematic
controller/controllee relation characteristic of obligatory control,
one will have to make reference to the semantic or, more precisely,
thematic properties of control-inducing predicates. This may have
implications for syntactic theories of obligatory control, whose aim
is to make predictions about controller/controllee relations solely in
syntactic terms. This case will also be relevant for the semantic
analyses that account for control solely in terms of entailment.
--Draga Zec
Everyone interested in the syntax and semantics of control constructions
and their implications for linguistic theory is invited. Written
copies of the paper are available at the CSLI Receptionist's desk.
!
Page 3 CSLI Newsletter December 5, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
PIXELS AND PREDICATES
Spatial Parsing for Visual Languages
Fred Lakin (Lakin@csli)
1:00 pm, Wednesday, December 11, CSLI trailers
Graphics are very important in human/computer interaction. To
participate effectively in this kind of interaction, computers must be
able to understand how humans use graphics to communicate. When a
person employs a text and graphic object in communication, that object
has meaning under a system of interpretation, or ``visual language''.
A first step toward computer understanding of the visual communication
objects used by humans is computer parsing of such objects, recovering
their underlying syntactic structure. The research described in this
paper combines computer graphics, symbolic computation and textual
linguistics to accomplish ``spatial parsing'' for visual languages.
Parsing has been investigated in four visual languages: VennLISP (a
visual programming language based on LISP), VIC (a visual
communication system for aphasics), FSA (finite state automaton)
diagrams, and SIBTRAN (graphic devices for organizing textual sentence
fragments). A parser has been written which can recover the structure
for graphic communication objects in the different visual languages.
In addition, interactive visual communication assistants utilize
modules from the parser to actively assist humans using two of the
visual languages.
----------
LOGIC SEMINAR
Proving Properties of Destructive LISP Programs (cont.)
Ian Mason, Philosophy Dept., Stanford
Friday, December 6, 12:00-1:00, Math. Faculty Lounge, Room 383-N
----------
ENVIRONMENTS GROUP MEETING
Grammar-writer's Workbench
Ronald Kaplan, Xerox and CSLI (Kaplan@xerox)
Monday, December 9, noon, Ventura Seminar Room
----------
PHONOLOGY/PHONETICS MEETING
Adequacy in Intonation Analysis: The Case of Dutch
Carlos Gussenhoven
Wednesday, December 11, 3:30, Ventura Conference Room
!
Page 4 CSLI Newsletter December 5, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
AFT MEETINGS
In the winter term, I shall start the regular meetings of the AFT
(Aitiational Frame Theory) Project on lexical representation. The
meetings will be once a week on Tuesdays at 11, and the first one will
be on January 14. The room will be announced later.
The project will be concerned with the construction of an adequate
theory of lexical representation and lexical meaning. While my
interests center around the AFT proposal, the main aim will be to
compare available theories of lexical meaning and come up with what
will seem to the group to be the best one.
In addition to the weekly meetings, there will be guest
presentations by speakers such as Joseph Almog (UCLA), Nathan Salmon
(UCSB), and Scott Soames (Princeton).
The following is a partial list of topics to be discussed.
a. Lexical meaning and the needed input for compositional semantics.
b. Lexical meaning and the needed input for syntax.
c. Lexical meaning and non-monotonic reasoning.
d. AFT and doubts about the claim that natural languages are formal
languages.
e. Lexical meaning and ``psychological reality.''
f. Lexical meaning, AFT, and morphology.
I would appreciate it if those who are interested in joining this
group would contact me via computer mail (Julius@csli) or phone
((415)497-2130) during the next couple of weeks. --Julius Moravcsik
-------
∂04-Dec-85 2141 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu Call for papers - Logic and Applications
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 21:41:11 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 4 Dec 85 21:26:33-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Wed 4 Dec 85 21:23:34-PST
Received: by rsch.wisc.edu; Wed, 4 Dec 85 23:11:52 CST
Date: Wed, 4 Dec 85 12:20:34 CST
From: udi@rsch.wisc.edu (Udi Manber)
Message-Id: <8512041820.AA06739@rsch.wisc.edu>
Received: by rsch.wisc.edu; Wed, 4 Dec 85 12:20:34 CST
To: udi@rsch.wisc.edu
Subject: Call for papers - Logic and Applications
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 04 Dec 85 23:11:15 CST (Wed)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
Sent by request of Ljubomir Ivanov
CALL FOR PAPERS
INTERNATIONAL SUMMER SCHOOL AND CONFERENCE
on
MATHEMATICAL LOGIC AND ITS APPLICATIONS
Dedicated to the 80th Anniversary of Kurt Godel
September 24 - October 3, 1986
Druzhba, Bulgaria
The meeting is organized by the Bulgarian Academy of Sciences, Sofia
University and the International Foundation `Ljudmila Zhivkova'.
The topics of the school and the conference are: mathematical logic and
the foundations of mathematics (set-theoretical mathematics,
constructive mathematics, intuitionism, proof theory); mathematical
logic and computer science (abstract recursion theory, theory of
computability, semantics of programming languages, logical programming,
logics of programs, logical problems of information retrieval);
mathematical logic, philosophy and the study of language (model and
other intensional logics, non-monotonic logic and other logical issues
in artificial intelligence).
The list of invited lecturers includes: J.W. deBakker, J.F.A.K. van
Benthem, A.G. Dragalin, Yu.L. Ershov, S.S. Goncharov, H. Jervell, Y.N.
Moschovakis, N.M. Nagornij, V.A. Nepomnjashchij, H. Rasiowa, G. Sambin,
K. Segerberg, N.A. Shanin, A. Skowron, V. Stoltenberg-Hansen, B.A.
Trakhtenbrot, V.A. Uspenskij.
Authors are invited to send three copies of a draft full paper by March
31, 1986 to the program committee chairman:
Dimitar G. Skordev
Section of Logic
Faculty of Mathematics
Sofia University
bul. Anton Ivanov 5
1126 Sofia, Bulgaria
(003592) 62561 (583)
The paper should be at most fifteen double-spaced typed pages, and
should present original contributions in the abovementioned areas. The
papers will be considered by the program committee (now under formation)
and authors will be notified of the acceptance or rejection by June 30,
1986. Accepted papers in final form are due to August 15, 1986 for
inclusion in the conference proceedings to be published by Plenum Press.
--------------
TN Message #12
--------------
∂05-Dec-85 0733 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #43
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 07:30:25 PST
Date: 5 Dec 85 0719-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #43
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Thursday, 5 Dec 1985 Volume 1 : Issue 43
Today's Topic:
Seminar: Limits on the Power of Concurrent-Write
Parallel Machines (MIT)
----------------------------------------------------------------------
Date: 12/04/85 18:17:14
From: LISA at MIT-MC.ARPA
Re: Beame's talk
[Forwarded from the MIT-MC BBoard by SASW@MIT-MC]
SEMINAR
DATE: Thursday, December 5, 1985
TIME: 3:45 p.m......Refreshments
4:00 p.m......Lecture
PLACE: MIT NE43 - 453
"LIMITS ON THE POWER OF CONCURRENT-WRITE PARALLEL MACHINES"
PAUL BEAME
University of Toronto
Abstract:
Concurrent-read concurrent-write parallel RAM's (CRCW PRAM'S) are very
powerful machines. They can compute any boolean function in constant
time given sufficiently many processors and sufficiently large memory.
Also they can compute simple functions like the boolean OR and the sum
of two n-bit numbers in constant time using a polynomial number of
processors and cells.
We consider powerful generalizationns of CRCW PRAM's which are
non-uniform and allow the individual processors an unlimited
instruction set. We show that for such machines if the number of
processors and cells is bounded by a polynomial in n then:
Computing the sum of n integers of n bits each requires
time THETA (log↑n).
Computing the parity of, sorting, or adding n input bits
require time OMEGA (sqrt {↑log↑n}).
The latter result uses a recent result of Hastad concerning unbounded
fan-in circuits.
HOST: David Shmoys
------------------------------
End of PARSYM Digest
********************
∂05-Dec-85 0958 REULING@SU-SCORE.ARPA CSD Mailing Lists
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 09:58:19 PST
Date: Thu 5 Dec 85 09:54:26-PST
From: John Reuling <Reuling@SU-SCORE.ARPA>
Subject: CSD Mailing Lists
To: faculty@SU-SCORE.ARPA, staff@SU-SCORE.ARPA
cc: Mailing-Lists@SU-SCORE.ARPA
Stanford: 206 Margaret Jacks Hall, +1 (415) 497-3549
Message-ID: <12164725771.23.REULING@SU-SCORE.ARPA>
[Summary: Send mailing-list errors to MAILING-LISTS@Score]
Please help us keep CSD's electronic mailing lists up to date.
If you send mail to a mailing list at Score and receive back an
error message from Mailer, please REMAIL or FORWARD the entire
error message to MAILING-LISTS@Score.
Here are a few of the larger mailing lists maintained on Score:
AC (Academic-Council) PhD-Adm
Admin Post-Docs
Colloq Programmers
CSD RAs
Faculty Sec (Secretaries)
Instructors SrStaff
Masters Staff
MSAI TAs
MSAI-Adm Trainers
PhD Visitors
Thank you.
-John Reuling
-------
∂05-Dec-85 1223 EMMA@SU-CSLI.ARPA Newsletter correction
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 12:23:01 PST
Date: Thu 5 Dec 85 11:40:27-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter correction
To: friends@SU-CSLI.ARPA
Tel: 497-3479
The name of the speaker for the December 12 colloquium is Bjorn
Lindblom not Lynn Bloom as stated in the newsletter. The abstract for
the colloquium follows.
CSLI COLLOQUIUM
Thursday, December 12, 1985, 4:15
Turing Auditorium (not Redwood Hall room G-19)
THEMES IN THE EVOLUTIONARY BIOLOGY OF LANGUAGE
A three-ring circus
Bjorn Lindblom, Peter MacNeilage, Michael Studdert-Kennedy
CASBS, Stanford
The goal of our research is summarized by the phrase: DERIVE LANGUAGE
FROM NON-LANGUAGE! We are exploring an approach to the biology of
language that is deliberately distinct from that pursued within
Chomskyan autonomous linguistics. We take as our first priority an
explicit search for precursors to all aspects of language structure
and speech behavior. By precursors we mean either evolutionary
precursors, traceable to lower animals, or those human but
non-linguistic, cognitive, perceptual and motor capacities that both
constrain language and make it possible. Only when a search for such
precursors has failed can we justly term some characteristic
unique---either to language or to man---and attribute it to some
species-specific bioprogram for language learning and use (cf.
universal grammar). In short, while we acknowledge and respect the
discoveries of formal linguistics, we believe that a sound approach to
the biology of language must go beyond form and structure to ask:
``How did language get that way?''
A major language universal for which any phylogenetic or ontogenetic
theory must account is LA DOUBLE ARTICULATION, or DUALITY of
patterning. We view the emergence of duality---that is, the use of
discrete elements and combinatorial rules at the two levels of
phonology and syntax---as the key to the communicative power of
language: duality provides a kind of impedance match between the
essentially unlimited semantics of cognition and a decidedly limited
set of signaling devices and processes.
Our central concern is with phonology: with the origin of discrete
phonological elements---phonemes and features---and with the processes
by which these intrinsically amodal elements are instantiated in the
modalities of production and perception. We shall review typological
facts about sound structure leading us to conclude that phonological
form adapts to the performance constraints of language use. How do we
choose our theoretical formalism for describing sound patterns?
Markedness theory or contemporary developments of generative phonology
and formal linguistics? No, since (i) spoken language is a product of
biological and cultural evolution; and (ii) there is considerable
empirical justification for viewing phonologies as adaptations to
biological and social selectional ⊂pressures the correct choice
appears to be some variant of the theoretical framework currently
explored by many students of biological and cultural evolution, viz.,
a Darwinian VARIATION*SELECTION model. In our talk we will present a
computational implementation of such a model. We will illustrate some
of its explanatory power by means of simulations indicating how a
number of typological facts can be predicted quantitatively and how
the emergence of ``a featural and segmental'' organization of lexical
systems can be derived in a self-organizing manner and deductively
(rather than just axiomatically). Drawing on corpora of speech error
data we describe the process by which discrete elements are organized
and sequenced in an actual utterance (phonologically and
syntactically) as one of inserting elements into a structured frame,
and, in our talk, we will consider the evolutionary relation between
this FRAME-CONTENT mode of organization and bimanual coordination.
Finally we will consider behavioral and neurophysiological evidence,
from both adults and children, consistent with a view of the
phonological element as an AMODAL structure linking production and
perception.
*Turing Auditorium is near Ventura Hall.
-------
∂05-Dec-85 1339 @SU-SCORE.ARPA:LES@SU-AI.ARPA Facilities action items
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 13:39:19 PST
Received: from SU-AI.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 13:12:49-PST
Date: 05 Dec 85 1315 PST
From: Les Earnest <LES@SU-AI.ARPA>
Subject: Facilities action items
To: faculty@SU-SCORE.ARPA
Here is background on two items that will be taken up at the Faculty
meeting on Tuesday, December 10.
APS Typesetter Aquisition
The Facilities Committee recommends that the department purchase the APS
typsetter from the TeX Project at depreciated cost (about $30,000) and
operate it as a cost center. The TeX Project has been operating the
typesetter as a facility for its own use but has made it available to
others in the department and elsewhere for books and other publications
(e.g. Star Labs reports, A.I. Magazine, Pat Winston's book). Outside
revenues were about $8,000 in 1984 and would have been much higher if Don
Knuth's typsetting had been charged for.
Two independent cost analyses by committee members indicate that there
would be little financial risk in taking on this responsibility. The
committee approved the proposal to acquire it with the understanding that
it will be operated as a low-overhead facility with minimal hand-holding
and little marketing. Faculty comments on this plan are invited.
Courtesy Computer Accounts
A report on problems with computer courtesy accounts is attached. The
Facilities Committee recommends that CSD adopt the policy shown at the
end, which is designed to deal with these problems.
Les Earnest
Facilities Committee Chair
-----------------------------------------------------------------------------
Courtesy Computer Accounts
Background
During the 22 years in which CSD has had its own computer facilities,
courtesy accounts have been extended to many outside users, often with
little serious justification. In fact, limited public access to SAIL was
permitted for people without *any* account up to the early '70s. While
the use of computer resources by guests sometimes inconvenienced other
users a bit, this permissiveness resulted in no direct economic losses to
the research programs or the department until recently. Given that some
of the department's computer facilities now run as cost centers, courtesy
accounts on these machines now consume some of our limited and precious
unrestricted funds.
The use of some courtesy accounts has persisted long past anyone's memory
of why they were created. There is also evidence of substantial waste and
abuse in the use of some accounts. It seems desirable to continue to
offer courtesy accounts, but we should ensure that the financial burden
does not become excessive and that the resources devoted to this activity
benefit the department. Toward this end, we need a clear policy and
administrative enforcement.
Current Use and Abuse
A scan of recent courtesy account billings reveals the following
distribution of users:
# Category
44 Former PhD students
8 Former CSD staff
1 Former CSD faculty
9 Friends of the Department
25 Unknown
--
93 Total
The "Friends of the Department" are faculty or researchers elsewhere
with close ties to the department.
Review of recent billings (May through August 1985) reveals that the
department has been paying about $18,000 a year for these 93 accounts.
These charges have been much larger than necessary for five main reasons:
(1) inactive accounts have not been purged and accrue substantial disk
storage charges;
(2) some hyperactive accounts have incurred inappropriately large charges;
(3) some courtesy users have been running on SCORE, which is a cost center,
when they could have been on SUSHI, which is not;
(4) once someone gets a courtesy account, there has been no systematic
record-keeping of why the account was set up nor any review of the
appropriateness of continuing it,
(5) the existing accounting system does not tell how much is being spent
on courtesy accounts.
The staff has done its best to cope with these problems but has been
hampered by a lack of clear policies. Working on point (3), for example,
the courtesy accounts of outside users on SCORE were shifted to SUSHI late
last summer and the accounts of Masters students will be shifted to SUSHI
soon. Though a partial purge was conducted this summer, there still
appear to be a number of people who have these accounts for no good reason.
37 courtesy accounts with no logins in 1985 have been incurring charges at
a rate over $5,000 per year. Some of these accounts have not been used
since 1980. Nevertheless, some are on distribution lists that cause their
mail files to keep growing.
Ignacio Zabala's account is a rather horrendous example. He received
his PhD three years ago, returned to Spain and has not logged in since.
In this time his mail file grew to the point where he alone has been
accounting for over $2000 a year in disk charges. (This account was
purged in early November at my request.)
It seems sensible to purge accounts that have been inactive for a long
time -- say, one year.
Of the courtesy accounts that are active, some are incurring very large
charges -- one person is currently running at a rate over $2000 per year,
another is just over $1000 and another 5 are each costing the department
over $500 a year. While Score software enforces account limitations,
SAIL does not. If we enforced a limit of, say, $120 per year per courtesy
account, we would save about $9,000 annually.
One of the reasons that the problems cited above were not noticed was that
the accounting system does not yield cost information on courtesy accounts
as a separate category -- these charges are intermixed with those of all
other users who are charged to the CSD Gift Account. In order to get the
data above it was necessary to extract records from detailed account
listings based on a line-by-line search, then total them separately.
Even if we set up a review procedure for courtesy accounts, there will
likely still be some abuses; e.g. some accounts may be "inherited" by
unauthorized users. We do not propose to expend effort on preventing this
kind of abuse, but it should be dealt with if evidence appears
fortuitously.
When a sponsored research project participant decides that a courtesy
account is needed for someone, he should normally arrange for the account
on the machine used by the project. If that machine is a cost center,
then the project should be expected to cover the cost of the account. In
any case, the project administration should keep track of the courtesy
account and ensure that it is closed when no longer appropriate.
It appears, then, that by adopting a few simple measures, the cost of
courtesy accounts can be reduced from $18,000 per year to $4,000 or less
while retaining the principal benefits of the existing program.
Recommendations
1. A policy such as the one given below should be adopted by the Department.
After adoption, all existing courtesy accounts should be reviewed for
consistency with the policy and exceptions should be dropped, with adequate
notice to the users.
2. The cost center accounting system should be modified to give separate
listings and totals on "subaccounts" -- subclasses of users who are
charged to the same University account. This will facilitate periodic
review of the costs of courtesy accounts and other user subgroups.
-----------------------------------------------------------------------
Policy on Courtesy Computer Accounts
PURPOSES. It is the policy of CSD to provide limited access to
departmental computer resources at no cost to certain people with close
ties to the department. The purpose of this access is to facilitate
communication with department members and to provide access to information
resources at Stanford. The departmental purpose is to stimulate exchanges
of information with outside members of computer research and teaching
communities and to engender goodwill.
INITIATION. Departing CSD students, faculty, and staff members will
normally be granted a grace period of up to 90 days to move or purge their
computer files if they request it in advance. Otherwise, files will be
purged on termination.
Individuals may be granted ongoing courtesy accounts upon approval by a
principal investigator or other person with account commitment authority.
Any cost of such courtesy accounts shall be charged to the University
accounts of the approving authority. Courtesy accounts on Department-
supported computers (e.g. SUSHI) or that are to be charged against
Departmental unrestricted funds shall be approved by the Department
Chairman. Individual charges against Departmental unrestricted accounts
shall not be permitted to exceed $10 per month.
Courtesy account users shall be informed that the account is for their
personal use and should not be made available to others. They shall
also be informed of any cost or other constraints on the use of the
account.
RECORDS AND REVIEW. For each courtesy account, whether it involves direct
charges or not, a record shall be kept of the reason the account was set
up, who approved it, and the termination date or conditions, if any.
Principal Investigators and the Department Chairman shall establish
procedures for periodically reviewing courtesy accounts to ensure that the
cost is consistent with their purposes and that they are terminated when
appropriate. Where possible, charge or resource constraints shall be
enforced automatically. Otherwise, accounts shall be reviewed by someone
monthly and appropriate action shall be taken to curb any abuses.
Accounts that are supported with Departmental funds that have not been
used for a year shall be purged whether or not there are direct charges
involved.
∂05-Dec-85 1402 TAJNAI@SU-SCORE.ARPA nominations for IBM fellowship
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 14:02:10 PST
Date: Thu 5 Dec 85 13:58:03-PST
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: nominations for IBM fellowship
To: faculty@SU-SCORE.ARPA
Message-ID: <12164770121.30.TAJNAI@SU-SCORE.ARPA>
Nominations are now open for the IBM fellowship. I am only
accepting nominations for CSD students (with the exception of
Ted Shortliffe's student); Sharon Gerlach will handle the
CSL/EE nominations.
Students must have passed their qualifying examination.
IBM does not disqualify non-citizens.
Nominations will close 5 p.m., Friday December 13.
Carolyn
-------
∂05-Dec-85 1514 NILSSON@SU-SCORE.ARPA Awards
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 15:13:56 PST
Date: Thu 5 Dec 85 15:06:58-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Awards
To: csd@SU-SCORE.ARPA
Message-ID: <12164782666.16.NILSSON@SU-SCORE.ARPA>
I recently received a letter regarding awards from Stanley Winker,
Chairman AFIPS awards committee. Attached are the main paragraphs from
that letter. Anyone interested in further info about this should stop
by my office and ask Anne Richardson for the referenced "enclosed"
information. -Nils
----
"As you may know, the deadline for nominations for the annual awards
of the American Federation of Information Processing Societies is
quickly approaching. In addition to AFIPS annual Education Award
and Harry Goode Memorial Award, this year AFIPS is pleased to announce
a new award, the Student History Best Paper Prize, which will honor
superior writing achievements of graduate and undergraduate students
in the area of computer history.
As Chairman of the Awards Committee I am writing to remind you that we
are accepting nominations through December for the Harry Goode and
Education Awards and through March 1st for the Student History Best
Paper Prize. I am certain there are members of your department
who will want to make nominations for these AFIPS awards, as well as
students who will wish to submit papers for the new Student History
Best Paper Prize. Enclosed is further information on the awards
and several nomination forms which you are encouraged to distribute
to all interested parties in your organization."
-----
-------
∂05-Dec-85 1718 ACUFF@SUMEX-AIM.ARPA I'll be gone for 6 days
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 17:18:35 PST
Date: Thu 5 Dec 85 17:16:27-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: I'll be gone for 6 days
To: ksl-lispm@SUMEX-AIM.ARPA
cc: ryalls@SUMEX-AIM.ARPA, sbarnes@SUMEX-AIM.ARPA, forbes@SUMEX-AIM.ARPA,
VELAZQUEZ@SUMEX-AIM.ARPA
Message-ID: <12164806238.48.ACUFF@SUMEX-AIM.ARPA>
I'll be away at a Common Lisp meeting until next Thursday.
Please refer emergencies having to do with Symbolics 36xx's or TI
Explorers to James Rice or an SSRG staff member, and send me mail
about others.
Thanks,
-- Rich
-------
∂05-Dec-85 2102 BRESNAN@SU-CSLI.ARPA morphology/syntax/discourse interactions
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 21:02:11 PST
Date: Thu 5 Dec 85 20:57:19-PST
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: morphology/syntax/discourse interactions
To: folks@SU-CSLI.ARPA
On Thursday, December 12, at 10:00 a.m. we will meet in the CSLI
Conference Room to hear the following exciting presentation. All
those interested are welcome.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Reflexivization Variation: Relations between Syntax, Semantics, and Lexical
Structure
Peter Sells, Annie Zaenen, Draga Zec
In this paper we examine the distinction between so-called transitive and
intransitive reflexive construction in several languages (English, Finnish,
German, Dutch, Chichewa, Warlpiri, Serbo-Croatian and Japanese). We argue
that three types of distinctions have to be made: transitivity versus
intransitivity in the lexicon, synthetic versus analytic forms in the
constituent structure and open versus closed predicates in the semantics;
thus there are three relevant levels of possible cross-linguistic
variation. While there is a one-way implication between lexical
intransitivity and closed predication, there are in general no direct
correlations between either the lexical forms or the semantic forms and
their constituent structure representation.
We give an account of the different types of reflexive that we discuss in
Lexical-Functional Grammar augmented with Discourse Representation
Structures.
Copies of the paper will be available at the front desk on Monday December
9th.
-------
-------
∂05-Dec-85 2158 JF@SU-SUSHI.ARPA help
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 21:58:19 PST
Date: Thu 5 Dec 85 21:56:13-PST
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: help
To: aflb.su@SU-SUSHI.ARPA
Message-ID: <12164857168.34.JF@SU-SUSHI.ARPA>
I need to send a message to theorynet. I tried my best guess based on
manber's last message telling us how to use the list, but I failed.
How are we supposed to use the theorynet list from stanford machines?
Thanks,
Joan
-------
∂05-Dec-85 2247 CAROL@SU-CSLI.ARPA New office
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 22:47:18 PST
Date: Thu 5 Dec 85 22:43:49-PST
From: Carol Kiparsky <CAROL@SU-CSLI.ARPA>
Subject: New office
To: Folks@SU-CSLI.ARPA
cc: Carol@SU-CSLI.ARPA
*********************************************************************
**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DL
Dec 5
Your itinerant dandelion consultant has yet another new office.
I'm now in the trailers, Room H-3. My phone numbers here are
723-5565 and 497-9030. The latter also rings in Marjorie's
office in case you need to leave a message.
Feel free to call or drop in. I'm usually here between 9:30 and
3:30.
-Carol
ION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION**NEWS**DLION*
*********************************************************************
-------
∂06-Dec-85 1003 CONTRERAS@SU-SCORE.ARPA Package
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 10:03:47 PST
Date: Fri 6 Dec 85 09:48:01-PST
From: Tina Contreras <CONTRERAS@SU-SCORE.ARPA>
Subject: Package
To: CSD@SU-SCORE.ARPA
Message-ID: <12164986745.20.CONTRERAS@SU-SCORE.ARPA>
There is a package here that someone tried to send to The Recruiting Office
of The Athletic Department, please come and claim this package at the
Reception desk. I.D. Mail will not take it.
Tina
-------
∂06-Dec-85 1300 YAMARONE@SU-CSLI.ARPA HOLIDAY PARTY NEXT FRIDAY(THE 13TH!)
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 13:00:20 PST
Date: Fri 6 Dec 85 12:55:43-PST
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: HOLIDAY PARTY NEXT FRIDAY(THE 13TH!)
To: FOLKS@SU-CSLI.ARPA
* * * * *
* * * * * *
* * * * * * *
* * * * * * * * *
* * * * * * * *
* * * * * * *
* * * *
* * * * * * *
* * * * * * *
* * * *
* * * ** *
* * * * *
* * * * * * *
* <↑> * * *
* ↑ * * ←←←←← *
* * /↑\ * | | *
/ \ | |
* * /~~~~'\ * * * --------- * *
* /'-/`' \ * / # # \ * *
* / ↑↑↑ * \ * ( ↑ )
/ \ * * `='
* / '~~~~~#~~`~~\ * * / \ *
* / * \ / \ *
* / ````++~~~~\ * * >--( CSLI )--< *
/ #~~~~~~~~~~~`....\ * ( ) *
* / \ * \=====/ *
/ +===`~~~~``~~~~~"''* \ * * / \ *
< & $ """"`=-` > * ( ) *
* ↑↑↑↑↑↑↑↑↑↑↑||||↑↑↑↑↑↑↑↑↑↑ ( ) *
|||| * ( ) *
|||| * \ / * *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'TIS THE SEASON TO BE JOLLY, FA LA LA LA LA LA LA LA LA
SINGING SONGS BY BUDDY HOLLY, FA LA LA LA LA LA LA LA LA
DON WE NOW OUR POT LUCK DISHES, FA LA LA LA LA LA LA LA LA
PREPARE DAVE HIS FAREWELL WISHES, FA LA LA LA LA LA LA LA LA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
NEXT FRIDAY , THE LUCKY 13TH, PREPARE YOURSELVES FOR THE
CCCCCCCC SSSSSS LLLLL IIIII
C C S S L I
C S L I
C S L I
C S L I
C SSSSS L I
C S L I
C S L I
C S L I
C C S S L L I
CCCCCCCC SSSSSS LLLLLLLLLLLLL IIIII
HOLIDAY POT-LUCK AND FAREWELL PARTY.
WE WILL BE CELEBRATING THE HOLIDAY SEASON AND SENDING DAVE
BROWN OFF TO PARTS-UNKNOWN IN THE SUBURBAN WASTELAND OF
GREATER LOS ANGELES........DRINKS AND THE GREATER PART OF
A MEAL WILL BE PROVIDED AND WE ASK THAT YOU BRING YOUR FAVORITE
SIDE DISH TO COMPLETE THIS POT-LUCK EXTRAVAGANZA.
LIVE ENTERTAINMENT WILL BE PROVIDED BY YOURS TRULY...
AND A FUN TIME IS GUARANTEED FOR ALL!! SO PLAN ON IT!!
SEE YOU THERE!!
CONSULT PARTY PLANNERS - SUSI, TOM OR JAMIE - FOR DETAILS!
-------
∂06-Dec-85 1309 YAMARONE@SU-CSLI.ARPA WHAT TIME'S THE PARTY BEGIN?
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 13:08:18 PST
Date: Fri 6 Dec 85 13:04:39-PST
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: WHAT TIME'S THE PARTY BEGIN?
To: FOLKS@SU-CSLI.ARPA
HEY, CAN YOU BELIEVE I DIDN'T MENTION A TIME FOR SUCH A LAVISH EVENT?
WHAT DO YOU SAY WE'LL BEGIN THE FESTIVITIES AT 3:00 AND BEGIN TO EAT
AND ENTERTAIN CLOSER TO 4:00?
OK, THAT'S THE TIME TABLE....REMEMBER, DON'T MAKE ANY DINNER PLANS
'CAUSE YOU'LL BE STUFFED AND STUMBLIN' WHEN YOU LEAVE HERE.
(THOSE WHO PRACTICE MODERATION, DON'T LET THIS STATEMENT UPSET YOU.)
BYE.
-------
∂06-Dec-85 1408 RICE@SUMEX-AIM.ARPA Explorers have new MIBs
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 14:07:57 PST
Date: Fri 6 Dec 85 14:05:47-PST
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: Explorers have new MIBs
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12165033670.72.RICE@SUMEX-AIM.ARPA>
New monitor interface boards have been put into explorers numbers 6, 8, 10, 11, 13 and 16. This should cure the problems with the spurious characters and the
vigorous auto repeat mode. If you see any more problems of this nature please
could you contact me or Mr. Acuff.
Rice.
-------
∂06-Dec-85 1423 @SU-CSLI.ARPA:PCOHEN@SRI-AI.ARPA Seminar by N. S. Sridharan, BBN Labs
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 14:23:47 PST
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Fri 6 Dec 85 14:18:52-PST
Date: Fri 6 Dec 85 14:19:06-PST
From: Phil Cohen <PCOHEN@SRI-AI.ARPA>
Subject: Seminar by N. S. Sridharan, BBN Labs
To: folks@SU-CSLI.ARPA
N. S. Sridharan, of BBN Labs, will give a seminar next Tues, the 10th,
in EJ228, title and abstract below.
Title: Semi-applicative Programming
Abstract:
Most current parallel programming languages are designed
with a sequential programming language as the base language and have
added constructs that allow parallel execution. We are experimenting
with an applicative base language that has implicit parallelism
everywhere, and then we introduce constructs that inhibit parallelism.
The base language uses pure LISP as a foundation and blends in
interesting features of Prolog and FP. Proper utilization of
available machine resources is a crucial concern of programmers. We
advocate several techniques of controlling the behavior of functional
programs without changing their meaning or functionality: program
annotation with constructs that have benign side-effects, program
transformation and adaptive scheduling. This combination yields us a
SEMI-APPLICATIVE programming language and an interesting programming
methodology.
Starting with the specification of a context-free recognizer, we have
been successful in deriving variants of the recognition algorithm of
Cocke-Kasami-Younger. One version is the CKY algorithm in parallel.
The second version includes a top-down predictor to limit the work
done by the bottom-up recognizer. The third version uses a cost
measure over derivations and produces minimal cost parses using a
dynamic programming technique. In another line of development, we
arrive at a parallel version of the Earley algorithm.
-------
∂06-Dec-85 1629 @SU-CSLI.ARPA:PCOHEN@SRI-AI.ARPA time for seminar by N. S. Sridharan
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 16:29:21 PST
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Fri 6 Dec 85 16:25:45-PST
Date: Fri 6 Dec 85 16:25:04-PST
From: Phil Cohen <PCOHEN@SRI-AI.ARPA>
Subject: time for seminar by N. S. Sridharan
To: folks@SU-CSLI.ARPA,
AIC-PStaff: ;
is 10:30 AM, in EJ228, SRI.
Sorry 'bout that!
Phil
-------
∂06-Dec-85 1634 PHILOSOPHY@SU-CSLI.ARPA colloquium
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 16:34:47 PST
Date: Fri 6 Dec 85 16:30:28-PST
From: Eve Wasmer <PHILOSOPHY@SU-CSLI.ARPA>
Subject: colloquium
To: bboard@SU-CSLI.ARPA
cc: folks@SU-CSLI.ARPA
Philosophy Department
Professor Susan Wolf
Philosophy Department
University of Maryland
Above and Below the Line of Duty
Monday, December l6, 3:15 p.m
Philosophy Seminar Room 92Q
-------
∂06-Dec-85 2050 @SU-SUSHI.ARPA:karp@ernie.berkeley.edu
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 20:49:57 PST
Received: from ucbvax.berkeley.edu by SU-SUSHI.ARPA with TCP; Fri 6 Dec 85 20:48:08-PST
Received: by ucbvax.berkeley.edu (5.31/1.7)
id AA01902; Fri, 6 Dec 85 09:38:06 PST
Received: by ernie (5.31/5.16)
id AA28232; Fri, 6 Dec 85 09:37:26 PST
Date: Fri, 6 Dec 85 09:37:26 PST
From: karp@ernie.berkeley.edu (Richard Karp)
Message-Id: <8512061737.AA28232@ernie>
To: aflb.local@su-sushi.arpa, allmsgs@ernie.berkeley.edu,
csfaculty@ernie.berkeley.edu, csmsgs@ernie.berkeley.edu,
theory-b@ernie.berkeley.edu, theory-f@ernie.berkeley.edu
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley, Ca. 94720 (415) 642-0143
Seminars in Computational Complexity
Tuesday, December 10 2:00 MSRI Lecture Hall
Jeff Lagarias "The Nonlinear Geometry of Linear Programming"
Tuesday, December 10 4:00 MSRI Lecture Hall
Peter Shor " Tight Bounds for Up-Right Matching, with Applications to Packing"
Thursday, December 12 4:00 MSRI Lecture Hall
George Lueker "Linear Programming with Two Variables per Inequality in Poly-Log
Time"
∂07-Dec-85 0846 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #44
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 7 Dec 85 08:46:53 PST
Date: 7 Dec 85 0824-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #44
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Saturday, 7 Dec 1985 Volume 1 : Issue 44
Response to PARSYM Hardware Survey:
SPUR (Berkeley)
[Responses are still welcome to the PARSYM Hardware Survey (V1 #33).
I don't expect you to neglect your Christmas shopping, but if you have
a moment, I'm sure the PARSYM readership would appreciate your
efforts. Please feel free to fill out only the first part of the
survey. To save you the trouble of looking up the back issue, the
"short form" is reproduced below. -- BD
The Third PARSYM Survey: Computer Hardware
(Reply to PARSYM-Survey@SUMEX-AIM.ARPA)
Part I
What computer hardware are you using or developing?
What are its components (processors, memory) and how many; how
do the processors and memory communicate?
SIMD/MIMD? Shared memory or distributed memory?
What model of concurrency are you investigating with this system?
What would you like to see in your next hardware system?
]
----------------------------------------------------------------------
From: larus@dali.berkeley.edu (James Larus)
Subject: PARSYM Survey, better late than ...
Date: 06 Dec 85 17:47:17 PST (Fri)
This response describes the SPUR project at UC Berkeley.
>> Part I (Easy)
>> What computer hardware are you using or developing?
We are developing a multiprocessor workstation called SPUR (Symbolic
Processing Using RISCs (Reduced Instruction Set Computers)).
>> What are its components (processors, memory) and how many; how do the
>> processors and memory communicate?
The processors are custom VLSI, similar to RISC II processors, with an
on-chip instruction buffer and some additional instructions to support
Lisp. Each processor has a coprocessor that supports IEEE standard
floating point and a large (128 Kbyte) cache.
We expect 6-10 processors will be the maximum that our current bus can
support.
>> SIMD/MIMD? Shared memory or distributed memory?
MIMD. There is a single, shared memory with a snooping cache scheme
to keep the per-processor caches consistent.
>> What model of concurrency are you investigating with this system?
We are investigating multiprocessor Lisp systems.
>> What would you like to see in your next hardware system?
It is a bit early to say, but a better bus would probably help a lot.
>> Part II (Optional, for extra credit)
>> 0. Project summary:
>> What model of concurrency (e.g., dataflow, communicating sequential
>> processes, actors, futures, etc.) is your work based on? What
>> language, if any, are you using in your work?
As mentioned above, we are implementing a multiprocess Lisp system.
yWe are looking at both the Multilisp and Qlambda approaches and are
trying to provide a set of primitives that will allow both techniques
to be implemented.
>> 1. Architectural classification:
>> SIMD or MIMD?
MIMD.
>> 2. Processing elements:
>> Describe each processor in the system in terms of type (e.g., 68000
>> equivalent, Lisp machine, custom), "power" (e.g., in MIPS or relative
>> to a Vax or 68000), and memory size. If the processors are simulated
>> then also describe the uniprocessor and mechanism for simulation. If
>> the processors in the system are not of uniform type then describe
>> each type and their relationship to each other.
The processors are all custom VLSI. They have run various Lisp
benchmarks from Gabriel's book roughly twice as fast as a Symbolics
3600 or VAX 8600. Their performance on C, Pascal, or Fortran should
be roughly comparable to a VAX 8600.
>> How many processors are there in the minimum and maximum configurations?
>> How many are you currently using?
Mimimum = 1. Maximum = 10 - 12. Currently we are simulating 1
processor.
>> 3. Memory system:
>> Describe how memory is distributed and accessed in the system. Shared
>> memory or distributed memory? Is there a single address space or does
>> each processor have its own address space? What sort of caching is
>> employed, if any: snoopy, write-through, or something else? What
>> sizes are the caches?
There is a single, shared memory. It has 256 1-gigabyte segments.
A processor can access 4 segments at once. Each processor has a 128
Kbyte cache that is kept consistent using a Snooping cache scheme.
>> What are the minimum and maximum amounts of memory? How much are you
>> currently working with?
No real limit on the size of the main memory, except cost and
packaging.
>> 4. Communication system:
>> How are processors connected to each other and to memory? Describe in
>> terms of topology (e.g., tree, systolic array, pipe, grid), switching
>> type (e.g., LAN, bus, Butterfly switch), and throughput (e.g., bus
>> transmission rates, time to access memory on remote nodes, time to
>> broadcast a message to all nodes).
The processors are connected to the main memory by a NuBus. They
communicate through the memory and asynchronous interrupts.
>> 5. Synchronization:
>> What hardware mechanisms does the system supply to support
>> synchronization?
Test-and-set instruction and inter-processor interrupts.
>> 6. Pragmatics
>> Is your system geared towards either specific programming languages or
>> applications?
The processors have some support for Lisp, though they should run
conventional languages (C, Pascal, etc.) as well. The applications
at which we are looking are "symbolic processing," i.e., compilation,
hardware simulation, etc.
>> Is the hardware of your system generally available or, if custom-made,
>> likely to be available in future?
The first set of workstations will be prototypes for use at Berkeley.
It is hoped that there will be a second design that will be done in
conjunction with a commercial vendor.
>> If you're now using a multiprocessor system, how does the architecture
>> of your development system correspond to your research target
>> architecture?
Not applicable.
>> What are the advantages of your hardware setup, particularly for the
>> problems you are investigating? What are the disadvantages? Is there
>> a system that would better meet your needs?
Ask again in 6 months or a year.
/Jim
------------------------------
End of PARSYM Digest
********************
∂08-Dec-85 2355 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #45
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 8 Dec 85 23:55:00 PST
Date: 8 Dec 85 2349-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #45
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Monday, 9 Dec 1985 Volume 1 : Issue 45
Today's Topics:
Seminar: Massively Parallel Networks That Learn Representations (MIT)
----------------------------------------------------------------------
Date: 12/06/85 10:35:37
From: ELIZABETH%MIT-OZ@MIT-MC.ARPA
Re: 9.382 --- Seminar in Visual Information Processing
[Forwarded from the MIT-BBoard by SASW@MIT-MC]
MASSIVELY PARALLEL NETWORKS THAT LEARN REPRESENTATIONS
Geoffrey Hinton
Carnegie-Mellon University
Monday, December 9
Eighth Floor Playroom, AI Lab
4:00 pm
I shall describe a new learning procedure for massively parallel
networks of neuron-like processing elements. The procedure adjusts
the connection strengths in a multi-layered network so as to make it
give the correct output vector when given an input vector. The units
in the intermediate layers come to represent important implicit
features of the task domain that generates the pairs of input/output
vectors. As a result, the network can generalise appropriately to new
cases. I shall describe a pattern recognition example in which the
network constructs a balanced ecology of feature detectors, and a
higher level task in which the network learns a set of relationships.
The second example illustrates the ability of the network to recognize
isomorphisms and make use of them in encoding and generalizing
knowledge.
------------------------------
End of PARSYM Digest
********************
∂09-Dec-85 1032 RICHARDSON@SU-SCORE.ARPA General Faculty Meeting
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 9 Dec 85 10:32:19 PST
Date: Mon 9 Dec 85 10:28:01-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: General Faculty Meeting
To: faculty@SU-SCORE.ARPA
Message-ID: <12165780460.17.RICHARDSON@SU-SCORE.ARPA>
Here is the agenda for tomorrow's general faculty meeting (Dec. 10) to be
held in MJH 146 from 1:15 to 3:45.
-------------------------------------------------------------------------
1. Reports
@ Financial, Betty Scott
(items: salary research offsets, ...)
@ Facilities, Lester Earnest
(items: Courtesy Computer Accts Policy, APS, Long-range Plans, ...)
@ PhD Program Committee Progress Report, Terry Winograd
@ Forum, Carolyn Tajnai
@ Others as may be appropriate
2. Report on Long-Range Planning Process, Nils Nilsson
3. Report on Undergraduate Major Planning
@ Curriculum Matters, Jeff Ullman and Stuart Reges
@ Summary of Curriculum approval process with UG Council and C-US,
Jeff Ullman and Nils Nilsson
@ Summary of discussions with Dean Gibbons regarding resources, Nils Nilsson
@ Discussion
4. Report on Progress on Searches, Nils Nilsson
@ Robotics
@ Systems
@ Possible New Searches
5. Proposed Consulting Professors (Tenenbaum and Hayes), Nils Nilsson
@ (curriculum vitaes distributed to faculty prior to meeting)
6. Status of New Patent and Copyrights Policy, Nils Nilsson
7. Proposal on "Visiting Professorship," John McCarthy and Nils Nilsson
8. Suggestion for a Survey of CSD Graduates, Bob Floyd
-------
∂09-Dec-85 1045 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 9 Dec 85 10:44:31 PST
Date: Mon 9 Dec 85 10:40:54-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
cc: library@SU-SCORE.ARPA, maslin@SUMEX-AIM.ARPA
Message-ID: <12165782805.17.RICHARDSON@SU-SCORE.ARPA>
Tomorrow is the final CSD Tuesday Lunch for the Fall Quarter in MJH 146 at
12:15. There will be general discussion of your choosing.
-------
∂09-Dec-85 1333 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books--CS
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 9 Dec 85 13:33:27 PST
Date: Mon 9 Dec 85 13:25:10-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books--CS
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA, cs%Playfair@SU-SCORE.ARPA
Message-ID: <12165812708.18.LIBRARY@SU-SCORE.ARPA>
Computer Speech Processing. by Frank Fallside and William Woods.
TK7895.S65F35 1985.
IEEE Computer Society. Proceedings. Trends and Applications 1985. Utilizing
Computer Graphics. May 1985. T385.T74 1985.
Self-Validating Numerics For Function Space Problems. Notes and Reports
in Computer Science and Applied Mathematics. by E. Kaucher and W. Miranker.
QA323.K38 1984.
Smart Robots; A Handbook Of Intelligent Robotic Systems. by Daniel Hunt.
TJ211.H86 1985 c.2
Applied Numerical Analysis. 3rd ed. by C. Gerald and P. Wheatley.
QA297.G47 1984 c.2
New Topics In Learning Automata Theory and Applications. by N. Baba.
Lecture Notes In Control and Information Sciences. Q335.B27 1984.
H. Llull
-------
∂09-Dec-85 1720 @SU-CSLI.ARPA:WALDINGER@SRI-AI.ARPA seminar on program transformation wednes, 3:45
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 9 Dec 85 17:20:01 PST
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Mon 9 Dec 85 17:16:55-PST
Date: Mon 9 Dec 85 17:09:43-PST
From: WALDINGER@SRI-AI.ARPA
Subject: seminar on program transformation wednes, 3:45
To: AIC-Associates: ;,
CSL: ;, su-bboards@SU-AI.ARPA, friends@SU-CSLI.ARPA, bboard@SRI-AI.ARPA
Title: A Closer Look at the Tupling Strategy for Program Transformation
Speaker: Alberto Pettorossi, IASI-CNR, Rome, Italy
Place: EK242 (Old AIC Conference Room), SRI International,
Ravenswood Avenue and Pine Street
Time: 3:45 pm Wednesday, 11 December
Coffee in Waldinger office at 3:15
Abstract:
Tupling is a strategy for transforming programs expressed as recursive
equations. We see how it applies to some challenging "little"
problems: the tower of Hanoi, the Chinese rings problem, drawing
Hilbert curves, and computing recurrence relations. We characterize
the power of the tupling strategy in terms of the structure of the
graphs we obtain by unfolding the functions of the programs.
-------
∂09-Dec-85 2250 DAVIES@SUMEX-AIM.ARPA AAP meeting Wednesday
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Dec 85 22:49:53 PST
Date: Mon, 9 Dec 1985 22:49 PST
Message-ID: <DAVIES.12165915422.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA, BHayes-Roth@SUMEX-AIM.ARPA
Subject: AAP meeting Wednesday
cc: Davies@SUMEX-AIM.ARPA
There will be a meeting this Wednesday at 9:30 am. One likely topic
is L100, James Rice's blackboard programming language. Also, we will
welcome our newest member, Hiroshi "Gitchang" Okuno.
-- Byron
∂10-Dec-85 1029 RICHARDSON@SU-SCORE.ARPA CSD Tuesday Lunch
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 10:29:31 PST
Date: Tue 10 Dec 85 10:25:48-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD Tuesday Lunch
To: faculty@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12166042201.14.RICHARDSON@SU-SCORE.ARPA>
Last lunch of the quarter today at 12:15 in MJH 146.
-------
∂10-Dec-85 1214 RICHARDSON@SU-SCORE.ARPA CSD 500 Colloquium Series
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 12:14:16 PST
Date: Tue 10 Dec 85 12:07:54-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: CSD 500 Colloquium Series
To: su-bboards@SU-SCORE.ARPA, colloq@SU-SCORE.ARPA, csd@SU-SCORE.ARPA
Message-ID: <12166060788.14.RICHARDSON@SU-SCORE.ARPA>
PLEASE NOTE THE NEW LOCATION FOR THE CS500 COLLOQUIUM SERIES TODAY (DEC.10)
DUE TO A SCHEDULING CONFLICT WITH A FINAL.
---------------------------------------------------------------------------
DAY December 10, 1985
EVENT Computer Science Colloquium
PLACE Terman Auditorium
TIME 4:15
TITLE A Knowledge-Based Approach to High-Level Program Optimization
PERSON Allen Goldberg
FROM Kestrel Institute and Univ. of California, Santa Cruz
A KNOWLEDGE-BASED APPROACH TO HIGH-LEVEL PROGRAM OPTIMIZATION
Our concern is the compilation of high-level declarative programs into
efficient Pascal-level implementations. Specifications are written as
equational assertions over a set-theoretic data domain. Compilation
is achieved by semi-automatic application of source-to-source
transformations. These transformations formalize knowledge about
high-level optimization techniques required for the task. These
techniques include finite differencing, loop fusion, algebraic
simplification, symbolic evaluation, data structure selection, and
store-vs-compute. The relevance of this work to the optimization of
Prolog and functional programs will be discussed.
-------
∂10-Dec-85 1235 DAVIES@SUMEX-AIM.ARPA Wednesday AAP meeting 9:30
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 12:35:01 PST
Date: Tue, 10 Dec 1985 12:34 PST
Message-ID: <DAVIES.12166065567.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: Wednesday AAP meeting 9:30
The topic of the Wednesday meeting is the concurrent blackboard
architecture TINA. People interested in implementing applications are
especially encouraged to attend.
-- Byron
∂10-Dec-85 1237 BROWN@SU-CSLI.ARPA Message for Sandwich
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 12:36:37 PST
Date: Tue 10 Dec 85 12:32:35-PST
From: Dave <BROWN@SU-CSLI.ARPA>
Subject: Message for Sandwich
To: folks@SU-CSLI.ARPA
There are 2 extra sandwiches today.....
1 Turkey
1 Turkey and avacado
-The Ventura Sandwich Corp.
-------
∂10-Dec-85 1319 LIBRARY@SU-SCORE.ARPA The Connection Machine by Hillis
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 13:19:35 PST
Date: Tue 10 Dec 85 13:11:58-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: The Connection Machine by Hillis
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA
Message-ID: <12166072449.21.LIBRARY@SU-SCORE.ARPA>
The Math/CS Library has The Connection Machine as a technical report
number 41646 and in the book collection under call number QA267.H487
1985. Enigneering Library also has a copy of the book. Our copy
is currently checked out (the book). If you wish to see it, send
a message and we will place you on the waiting list.
H. Llull
-------
∂10-Dec-85 1834 ullman@su-aimvax.arpa tomorrow's meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 18:34:52 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 10 Dec 85 18:30:41 pst
Date: Tue, 10 Dec 85 18:30:41 pst
From: Jeff Ullman <ullman@diablo>
Subject: tomorrow's meeting
To: nail@diablo
As usual, we have no official program.
However, several people have been talking to me about what looks
like almost the same problem, and I'd like to get a discussion
going (you know who you are).
The general area is what happens when we expand a rule or rules
to get an infinite sequence of relational algebra expressions,
and we want to prove some property holds for all (or almost
all, or for an infinite number) of these expressions.
Meet at 11AM.
---Jeff
∂10-Dec-85 2226 vardi@su-aimvax.arpa Database Seminar
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 22:26:18 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 10 Dec 85 22:23:15 pst
Date: Tue, 10 Dec 85 22:23:15 pst
From: Moshe Vardi <vardi@diablo>
Subject: Database Seminar
To: nail@diablo
From @SU-SCORE.ARPA:MILTON@SRI-AI.ARPA Tue Dec 10 00:57:03 1985
Received: from SU-SCORE.ARPA by su-aimvax.arpa with Sendmail; Tue, 10 Dec 85 00:56:59 pst
Received: from SRI-AI.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Dec 85 00:53:39-PST
Date: Tue 10 Dec 85 00:55:18-PST
From: MILTON@SRI-AI.ARPA
Subject: Database Research Seminar for 12/13
To: CS545:;
We will meet this Friday at 3:15 in room 352 MJH for the last seminar of the
quarter --
Integrating Databases and Logic Based AI Representation Systems
Richard Weyhrauch
Stanford University
The recognition that relational data bases can be directly viewed as a
model for a first order theory is now well understood. We will give a
formal presentation of FOL, a reformulation of first order logic, that
will make data base access, reasoning about data and using meta theoretic
reasoning available in the same system. One example of the power of this
system is the ability to distinguish explicitly between making the closed
world assumption and the case where the data base is simply incomplete.
-------
∂11-Dec-85 0617 PATASHNIK@SU-SUSHI.ARPA Last AFLB of the quarter
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 11 Dec 85 06:15:38 PST
Date: Wed 11 Dec 85 06:12:01-PST
From: Oren Patashnik <PATASHNIK@SU-SUSHI.ARPA>
Subject: Last AFLB of the quarter
To: aflb.all@SU-SUSHI.ARPA
Message-ID: <12166258145.8.PATASHNIK@SU-SUSHI.ARPA>
Here's the abstract for the last AFLB of the quarter. Also, later in
day there's another talk that might be of interest; details follow
the AFLB abstract.
**************************************************
12-Dec-85 : Joan Hutchinson (MSRI & Smith College)
Results and Algorithms in Topological Graph Theory
In this seminar I will present results on "separating" algorithms and
"planarizing" algorithms for graphs of bounded genus. Namely, given a
graph with n vertices and genus g we look for a set of O(sqrt(gn))
vertices whose removal leaves all components of size at most 2n/3 and
a set of O(sqrt(gn)) vertices whose removal leaves a planar graph. As
time permits I will also discuss Robertson and Seymour's recent work
that provides polynomial time algorithms for these problems:
i) for fixed k, upon input G and k pairs of vertices (s←i,t←i) of G,
determine whether there are k vertex-disjoint paths joining s←i and
t←i for i=1..k.
ii) for a fixed graph H, determine whether G contains H as a minor.
***** Time and place: December 12, 12:30 pm in MJ352 (Bldg. 460) ******
Additional talk:
Department of Mathematics Colloquium
Prof. Wolfgang Maass - MSRI & Univ. of Illinois, Chicago Circle
"Lower Bound Arguments for Turing Machines"
Thursday, December 12, 4:15 p.m.
Bldg 380 (Math), Room 380-W
**************************************************
Regular AFLB meetings are on Thursdays, at 12:30pm, in MJ352. If you
have a topic you'd like to talk about please let me know. (Electronic
mail: patashnik@su-sushi.arpa, phone: (415) 497-1787). Contributions
are wanted and welcome. Not all time slots for this academic year
have been filled. The file [SUSHI]<patashnik.aflb>aflb.bboard contains
more information about future and past AFLB meetings and topics.
--Oren Patashnik
-------
∂11-Dec-85 1424 RICE@SUMEX-AIM.ARPA Today's talk.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 11 Dec 85 14:23:33 PST
Date: Wed 11 Dec 85 14:22:46-PST
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: Today's talk.
To: aap@SUMEX-AIM.ARPA
Message-ID: <12166347483.17.RICE@SUMEX-AIM.ARPA>
If anyone want Xeroces of the slides of the proto worked examples please
come and see me. I also have a few sets of the manuals left over for
anyone who failed to get them today.
Rice.
-------
∂11-Dec-85 1436 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:udi@rsch.wisc.edu Technical Debate at Stanford on SDI, December 19
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 11 Dec 85 14:36:23 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Wed 11 Dec 85 14:32:00-PST
Received: from rsch.wisc.edu by SU-SCORE.ARPA with TCP; Wed 11 Dec 85 14:32:00-PST
Received: by rsch.wisc.edu; Wed, 11 Dec 85 16:13:50 CST
Received: from SU-SUSHI.ARPA by rsch.wisc.edu; Wed, 4 Dec 85 21:05:08 CST
Date: Wed 4 Dec 85 15:50:28-PST
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: Technical Debate at Stanford on SDI, December 19
To: theory@rsch.wisc.edu
Message-Id: <12164528442.63.JF@SU-SUSHI.ARPA>
Status: R
Resent-To: TheoryNet-list@rsch.wisc.edu
Resent-Date: 11 Dec 85 16:12:45 CST (Wed)
Resent-From: Udi Manber <udi@rsch.wisc.edu>
``SDI: How Feasible, How Useful, How Robust?''
This will be a technical debate, covering both hardware and software aspects
of SDI.
The debate will be videotaped by the Stanford Instructional Television Network.
Sponsor: Stanford Computer Science Department
Date: December 19, 1985
Time: 8:00 p.m.
Place: Terman Auditorium
Organizer: Barbara Simons, IBM-SJ
Moderator: Dr. Marvin L. Goldberger, President of Cal Tech.
Former member of President's Science Advisory Committee
and Consultant on Arms Control and International Security.
Panelists:
Opponents:
Dr. Richard L. Garwin, IBM Fellow and Adjunct Professor of Physics at
Columbia University, Physicist and Defense Consultant.
Professor David Parnas, Lansdown Professor of Computer Science at the
University of Victoria, Former member of the SDI Organization's
Panel on Computing and Support of Battle Management.
Advocates:
Professor Richard Lipton, Professor of Computer Science at Princeton
University, Current member of SDIO's Panel on Computing and Support of Battle
Management.
Major Simon Peter Warden, the Special Assistant to the Director of the SDIO
and Technical Advisor to the Nuclear and Space Arms Talk with the USSR
in Geneva.
--------------
TN Message #13
--------------
∂11-Dec-85 1752 EMMA@SU-CSLI.ARPA Newsletter December 12, No. 5
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 11 Dec 85 17:52:20 PST
Date: Wed 11 Dec 85 17:07:17-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter December 12, No. 5
To: friends@SU-CSLI.ARPA
Tel: 497-3479
!
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
December 12, 1985 Stanford Vol. 3, No. 5
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR *THIS* THURSDAY, December 12, 1985
12 noon TINLunch
Ventura Hall Plural Determiners and Plural Anaphora
Conference Room by Werner Frey and Hans Kamp
Discussion led by Werner Frey
(Abstract on page 1)
2:15 p.m. CSLI Seminar
No seminar this week
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Themes in the Evolutionary Biology of Language:
A three-ring circus
Bjorn Lindblom, CASBS
(Abstract on page 2)
--------------
ANNOUNCEMENT
Please note that the seminar and colloquium are no longer in Redwood
Hall room G-19. The new room is Turing Auditorium in Jordan Quad.
--------------
THIS WEEK'S TINLUNCH
Plural Determiners and Plural Anaphora
Werner Frey, University of Texas
Werner Frey will discuss his and Hans Kamp's work on plural noun
phrases, focusing on:
a) The interpretation of anaphoric plural pronouns, with special
attention to the ways in which it differs from that of singular
pronouns.
b) The difference between definite plural NP's, such as `the boys'
and `indefinite' plurals, such as e.g., `many boys'.
c) The nature of the definite article `the', both in its plural and
its singular uses.
Copies of a longer abstract will be available at the Ventura desk.
!
Page 2 CSLI Newsletter December 12, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
THIS WEEK'S COLLOQUIUM
Themes in the Evolutionary Biology of Language: A three-ring circus
Bjorn Lindblom, Peter MacNeilage, Michael Studdert-Kennedy, CASBS
The goal of our research is summarized by the phrase: DERIVE
LANGUAGE FROM NON-LANGUAGE! We are exploring an approach to the
biology of language that is deliberately distinct from that pursued
within Chomskyan autonomous linguistics. We take as our first priority
an explicit search for precursors to all aspects of language structure
and speech behavior. By precursors we mean either evolutionary
precursors, traceable to lower animals, or those human but
non-linguistic, cognitive, perceptual and motor capacities that both
constrain language and make it possible. Only when a search for such
precursors has failed can we justly term some characteristic
unique---either to language or to man---and attribute it to some
species-specific bioprogram for language learning and use (cf.
universal grammar). In short, while we acknowledge and respect the
discoveries of formal linguistics, we believe that a sound approach to
the biology of language must go beyond form and structure to ask:
``How did language get that way?''
A major language universal for which any phylogenetic or
ontogenetic theory must account is LA DOUBLE ARTICULATION, or DUALITY
of patterning. We view the emergence of duality---that is, the use of
discrete elements and combinatorial rules at the two levels of
phonology and syntax---as the key to the communicative power of
language: duality provides a kind of impedance match between the
essentially unlimited semantics of cognition and a decidedly limited
set of signaling devices and processes.
Our central concern is with phonology: with the origin of discrete
phonological elements---phonemes and features---and with the processes
by which these intrinsically amodal elements are instantiated in the
modalities of production and perception. We shall review typological
facts about sound structure leading us to conclude that phonological
form adapts to the performance constraints of language use. How do we
choose our theoretical formalism for describing sound patterns?
Markedness theory or contemporary developments of generative phonology
and formal linguistics? No, since (i) spoken language is a product of
biological and cultural evolution; and (ii) there is considerable
empirical justification for viewing phonologies as adaptations to
biological and social selectional pressures the correct choice appears
to be some variant of the theoretical framework currently explored by
many students of biological and cultural evolution, viz., a Darwinian
VARIATION*SELECTION model. In our talk we will present a computational
implementation of such a model. We will illustrate some of its
explanatory power by means of simulations indicating how a number of
typological facts can be predicted quantitatively and how the
emergence of ``a featural and segmental'' organization of lexical
systems can be derived in a self-organizing manner and deductively
(rather than just axiomatically). Drawing on corpora of speech error
data we describe the process by which discrete elements are organized
and sequenced in an actual utterance (phonologically and syntactically)
as one of inserting elements into a structured frame, and, in our
talk, we will consider the evolutionary relation between this
FRAME-CONTENT mode of organization and bimanual coordination. Finally
we will consider behavioral and neurophysiological evidence, from both
adults and children, consistent with a view of the phonological
element as an AMODAL structure linking production and perception.
!
Page 3 CSLI Newsletter December 12, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
Reflexivization Variation:
Relations between Syntax, Semantics, and Lexical Structure
Peter Sells, Annie Zaenen, Draga Zec
Thursday, December 12, 10:00, Ventura Conference Room
In this paper we examine the distinction between so-called
transitive and intransitive reflexive construction in several
languages (English, Finnish, German, Dutch, Chichewa, Warlpiri,
Serbo-Croatian and Japanese). We argue that three types of
distinctions have to be made: transitivity versus intransitivity in
the lexicon, synthetic versus analytic forms in the constituent
structure and open versus closed predicates in the semantics; thus
there are three relevant levels of possible cross-linguistic
variation. While there is a one-way implication between lexical
intransitivity and closed predication, there are in general no direct
correlations between either the lexical forms or the semantic forms
and their constituent structure representation.
We give an account of the different types of reflexive that we
discuss in Lexical-Functional Grammar augmented with Discourse
Representation Structures.
Copies of the paper are available at the front desk.
----------
CSLI SEMINAR
NETTALK: Teaching a Massively-Parallel Network to Talk
Terrence J. Sejnowski, Johns Hopkins
1:00pm, Wednesday, December 18, CSLI trailers
A special seminar in place of Pixels and Predicates
Text to speech is a difficult problem for rule-based systems
because English pronunciation is highly context dependent and there
are many exceptions to phonological rules. An alternative knowledge
representation for correspondences between letters and phonemes will
be described in which rules and exceptions are treated uniformly and
can be determined with a learning algorithm in a connectionist model.
The architecture is a layered network of 400 simple processing units
with 9,000 weights on the connections between the units. The training
corpus is continuous informal speech transcribed from tape recordings.
Following training on 1000 words from this corpus the network can
generalize to novel text. Even though this network was not designed
to mimic human learning, the development of the network in some
respects resembles the early stages in human language acquisition.
Following damage of the network by either removal of units or addition
of random values to the weights the performance of the network
degraded gracefully. Issues which will be addressed include scaling
of the learning algorithm with the size of the problem, robustness of
learning to predicate order of the problem, and universality of
learning in connectionist models.
!
Page 4 CSLI Newsletter December 12, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
ENVIRONMENTS GROUP MEETING
DefinitionGroups: Organizing Programs in Time and Space
Daniel Bobrow, Xerox PARC
Monday, 12:00, December 16, Ventura Trailers
Most current systems use files for long term storage, and to
organize the conceptual structure of the system. The definition
groups project (with Daniel Bobrow, David Fogelsong and Mark Miller)
is exploring an object oriented approach to the organization of a
system, and to the maintenance of sequential incremental changes. It
will also support the exploration of alternative development paths.
Extensive use of browsers allows alternative views and interaction
with the program structure.
DEFGROUPS uses current file system as a base, but is set up to move
to a database system. A prototype of the system is currently working,
and supporting its own development.
-------
∂12-Dec-85 0902 LIBRARY@SU-SCORE.ARPA USENIX and UNIFORUM Conference Proceedings
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 09:01:59 PST
Date: Thu 12 Dec 85 08:58:09-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: USENIX and UNIFORUM Conference Proceedings
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA, mogul@SU-SCORE.ARPA
Message-ID: <12166550534.28.LIBRARY@SU-SCORE.ARPA>
I received a message today that a number of people are interested in the
library having USENIX Association conference proceedings. I have order
these conferences along with the UniForum Conferences from the same
association. I appreciate receiving requests like this whether or not
I have already order it or not. It helps me monitor the level of interest
and change in that interest in the various research areas. Please feel
free to make suggestions for new purchases by sending me messages
Library@Score.
Harry Llull
-------
∂12-Dec-85 0943 YAMARONE@SU-CSLI.ARPA HOLIDAY CELEBRATION REMINDER
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 09:43:47 PST
Date: Thu 12 Dec 85 09:34:02-PST
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: HOLIDAY CELEBRATION REMINDER
To: FOLKS@SU-CSLI.ARPA
TOMORROW, TOMORROW, WE'LL PARTY TOMORROW,
IT'S ONLY A DAY AWAY...........
* * * * *
* * * * * *
* * * * * * *
* * * * * * * * *
* * * * * * * *
* * * * * * *
* * * *
* * * * * * *
* * * * * * *
* * * *
* * * ** *
* * * * *
* * * * * * *
* <↑> * * *
* ↑ * * ←←←←← *
* * /↑\ * | | *
/ \ | |
* * /~~~~'\ * * * --------- * *
* /'-/`' \ * / # # \ * *
* / ↑↑↑ * \ * ( ↑ )
/ \ * * `='
* / '~~~~~#~~`~~\ * * / \ *
* / * \ / \ *
* / ````++~~~~\ * * >--( CSLI )--< *
/ #~~~~~~~~~~~`....\ * ( ) *
* / \ * \=====/ *
/ +===`~~~~``~~~~~"''* \ * * / \ *
< & $ """"`=-` > * ( ) *
* ↑↑↑↑↑↑↑↑↑↑↑||||↑↑↑↑↑↑↑↑↑↑ ( ) *
|||| * ( ) *
|||| * \ / * *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'TIS THE SEASON TO BE JOLLY, FA LA LA LA LA LA LA LA LA
SINGING SONGS BY BUDDY HOLLY, FA LA LA LA LA LA LA LA LA
DON WE NOW OUR POT LUCK DISHES, FA LA LA LA LA LA LA LA LA
PREPARE DAVE HIS FAREWELL WISHES, FA LA LA LA LA LA LA LA LA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TOMORROW, FRIDAY , THE LUCKY 13TH, PREPARE YOURSELVES FOR THE
CCCCCCCC SSSSSS LLLLL IIIII
C C S S L I
C S L I
C S L I
C S L I
C SSSSS L I
C S L I
C S L I
C S L I
C C S S L L I
CCCCCCCC SSSSSS LLLLLLLLLLLLL IIIII
HOLIDAY POT-LUCK AND FAREWELL PARTY.
WE WILL BE CELEBRATING THE HOLIDAY SEASON AND SENDING DAVE
BROWN OFF TO PARTS-UNKNOWN IN THE SUBURBAN WASTELAND OF
GREATER LOS ANGELES........DRINKS AND THE GREATER PART OF
A MEAL WILL BE PROVIDED AND WE ASK THAT YOU BRING YOUR FAVORITE
SIDE DISH TO COMPLETE THIS POT-LUCK EXTRAVAGANZA.
LIVE ENTERTAINMENT WILL BE PROVIDED BY THE FOLK/ROCK/
CHRISTMAS-SONG DUO OF JOHN JOSEPH AND TOM YAMARONE..
AND A FUN TIME IS GUARANTEED FOR ALL!! SO PLAN ON IT!!
FESTIVITIES BEGIN AT 4:00 PM
POT-LUCK "DINNER" BEGINS AT 5:00 PM.
HOPE TO SEE YOU THERE!!!
-------
∂12-Dec-85 1116 GOTELLI@SU-SCORE.ARPA Correction
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 11:16:32 PST
Date: Thu 12 Dec 85 11:08:04-PST
From: Lynn Gotelli <GOTELLI@SU-SCORE.ARPA>
Subject: Correction
To: csd@SU-SCORE.ARPA
Message-ID: <12166574183.10.GOTELLI@SU-SCORE.ARPA>
Dan Kolkowitz will be moving into MJH030B sometime after the
first of the year NOT MJH030C.
-------
∂12-Dec-85 1136 GOTELLI@SU-SCORE.ARPA New Staff Member
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 11:36:47 PST
Date: Thu 12 Dec 85 10:52:33-PST
From: Lynn Gotelli <GOTELLI@SU-SCORE.ARPA>
Subject: New Staff Member
To: csd@SU-SCORE.ARPA
Message-ID: <12166571357.10.GOTELLI@SU-SCORE.ARPA>
Please welcome Dan Kolkowitz who joins us in Computer Facilities
and will be responsible for the operation and software support
of the CF unix systems. Dan can be found temporarily in MJH040D
until the end of the year when he will move into MJH030C. We
are very happy to have Dan as a member of our staff.
-------
∂12-Dec-85 1238 ullman@su-aimvax.arpa Recent developments
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 12:38:13 PST
Received: by su-aimvax.arpa with Sendmail; Thu, 12 Dec 85 12:31:26 pst
Date: Thu, 12 Dec 85 12:31:26 pst
From: Jeff Ullman <ullman@diablo>
Subject: Recent developments
To: nail@diablo
Those who left early (i.e., before 2PM) missed a good NAIL! meeting.
I'm going to try to sumarize the things that Jeff N., Allen, Shuky,
and I worked on. We focussed on fixed points of monotone functions.
That is, let f be a function from k-ary relations to k-ary relations,
such that if X C← Y, then f(X) C← f(Y). [I'll use C← for "contained in"]
The principal source we have in mind for such function is SyRipS,
e.g, a rule like T(X,Y) :- E(X,Z) & T(Z,Y) defines the function
from T to T: f(T) = PROJ←{1,3}(E*T), i.e, the projection onto
columns 1 and 3 of the natural join of E and T.
However, we might like to use some f that does not come from a single rule.
Let f↑i be the composition of f with itself i times, and f* be the union
of f↑i for all i >= 1.
In what follows, it is important to remember that we are using the
"sigma" (Shuky's term) or "all-models" interpretation of functions.
That is, to say f C← g is to say that f(X) C← g(X) for all relations X.
f = g means the "containment" goes both ways.
We also assume that what we really want to know about is
the result of applying the function until a fixed point is reached.
This interpretation is equivalent to saying that for two rules to be
"equal" they must produce the same value for their predicate p when
started with p equal to an arbitrary relation,
and the rules are then applied until convergence occurs.
In comparison, the more conventional, but less tractable definition of
equivalence is to say that rules are equal if their least fixed points,
i.e., their results started with p empty, are the same.
The problem we would like to address is: given a monotone function f,
what is its "minimal" equivalent function? In order to attack that
question, we at least have to answer the question whether two functions,
f and g are equivalent in the all-models sense, i.e., is f*=g*?
Shuky pointed out a while ago that if f and g come from full Datalog
rules ("full" in this sense means that a variable appearing in
the head also appears somewhere in the body.) then equivalence
of f* and g* is the same as testing whether f and g are equivalent
as dependencies, and thus f* = g* is decidable.
However, we still need efficient decision procedures for subcases.
LEMMA: f* C← g* if and only if f C← g↑i for some i.
COROLLARY: f* = g* iff f C← g↑i and g C← f↑j for some i and j.
Say f is containment-free if for no i>1 is f C← f↑i.
The test for f* = g* appears to depend significantly on whether
f or g are containment-free.
THEOREM: If f is containment-free then f* = g* iff f = g.
Note that for sufficiently general f and g, even testing f = g
might not be decidable. However, for reasonable classes of functions,
f = g is easy to decide, e.g., if f and g are tableau mappings.
A similar issue comes up for deciding whether f (or g) is containment-free.
I think a lot of what Jeff N. has done regarding data-independent
recursion can be applied here.
The above theorem has an interesting partial converse.
THEOREM: if there is some i such that f is *properly* contained
in f↑i, then there is always some g (namely g= f↑i) such
that f* = g*, yet f != g.
The interesting case that remains is: what happens if f
is not containment-free, but there is no proper containment, i.e.,
f = f↑i for some i.
In this case, f is bounded, in the sense that f*
is equal to finite unions of powers of f. However, some f's
have a g for which f* = g*, but f != g, and some do not.
The function PROJ←{2,3,1}, i.e., the function that cycles the
columns of a ternary relation, is an example of an f for which
g exists; g = PROJ←{3,1,2}.
On the other hand, the identity function f has no such g.
OPEN PROBLEMS:
It is interesting to suppose that functions f could be divided
into two classes: those that are containment-free and those that
are bounded, i.e., f = f↑i for some i>1.
If we can pick f's from a sufficiently rich class, that isn't true.
For example, Allen suggested the following function:
f(R) = I union PROJ←{1,3}(E*R)
where I is the set of pairs (x,x) such that x is a "node", and
f↑i is the set of (x,y) such that there is a path of edges E
from x to y, of length <= i.
Then f↑i C← f↑{i+1} for some i, in fact for any i, yet for no
i is f = f↑i.
Jeff N. also contributes the following example. The recursion
is data dependent (therefore not bounded), there is only
one rule, yet the function f defined by the rule is not
containment-free.
t(X,Y) :- t(X,W) & e(W,W) & e(W,Y)
If t←0 is the initial value of t, then
f(t←0) is defined by t(X,Y) :- t←0(X,W←0) & e(W←0,W←0) & e(W←0,Y)
while f↑2(t←0) is given by
t(X,Y) :- t←0(X,W←1) & e(W←1,W←1) & e(W←1,W←0) & e(W←0,W←0) & e(W←0,Y)
(i.e., the project-join formulas for f and f↑2 are the ones
implied by these rules)
It is easy to check that f C← f↑2 but not vice-versa, using
the idea of tableau mappings.
We conjecture that the dichotomy containment-free/bounded appears
when f is chosen from a sufficiently simple class, perhaps even
for all single-rule, linear logic programs with no repeated predicates.
Note Allen's example requires two rules to define R, and Jeff's
uses two occurrences of E and also uses variable repetition.
We also would like to see classes for which there is an efficient
test for the containment-free property, and classes for which
f = g (as mappings, not fixpoints) is easy.
Finally, we are not really especially interested in the equivalence
problems; we really want efficient procedures for deciding, given
f, what is the "smallest" g such that f* = g*.
Perhaps the theory suggested above can help with this optimization
problem, e.g., by showing that in many cases, the opt. question
reduces to "find a smallest g such that f = g."
∂12-Dec-85 1537 ullman@su-aimvax.arpa oops
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 15:36:18 PST
Received: by su-aimvax.arpa with Sendmail; Thu, 12 Dec 85 15:32:01 pst
Date: Thu, 12 Dec 85 15:32:01 pst
From: Jeff Ullman <ullman@diablo>
Subject: oops
To: nail@diablo
That message I sent out has at least two flaws, pointed out by Vlad
Lifshitz.
1. Minor point: I didn't mean to say that f* C← g* iff f C← g↑i
for some i applied for any f and g, but only for the case of
tableau mappings. The result depends on the Sagiv-Yannakakis
theorem about when unions of tableau mappings are equivalent,
and is just one of the ways in which tableaux are special in useful ways.
2. More importantly, while I glibly talked about logic programs
as "functions," really they are parametized functions.
The "parameter" is the database.
Thus, given the simple transitive closure rules:
t(X,Y) :- t(X,Z) & e(Z,Y)
we really have one function f←e for each database e.
The theorem I stated is still true about any f←e; that is,
if f←e is never a subset of (f←e)↑i, for i>1, then
(f←e)* = (g←e)* iff f←e = g←e.
However, the worrisome thing is that there might be some way
to optimize program f, say by replacing it by program g,
such that (f←e)* = (g←e)* for any e, yet it was not true
that f←e = g←e for the following reason:
There were some e for which f←e is containment-free.
In those cases, f←e = g←e. There were other e for which
f←e C← (f←e)↑i, and in those cases, f←e != g←e.
Thus, we could not optimize f by looking for g's for which
f←e = g←e.
Unfortunately, we cannot avoid this problem by defining "containment-free"
to mean that f←e is containment-free for all e; the problem
is that almost any nontrivial program will have SOME e for
which that is false, e.g., e = EMPTY SET means that th transitive
closure program does not have the c.f. property.
I'm not sure what to do. What comes to mind is that when
we ask whether f←e = g←e, we do not want to ask whether that
is true for all e, but only for those e's satisfying a certain
condition (that e doesn't induce the a containment on the program of f).
That sounds like the old idea of equivalence of tableau mappings
on only those databases that satisfy certain dependencies,
and we were able to figure out how to do that, so perhaps we
can crack this one, but it is harder than it looked.
---Jeff
∂13-Dec-85 0843 TAJNAI@SU-SCORE.ARPA Contacts at Apple
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 08:42:57 PST
Date: Fri 13 Dec 85 08:27:13-PST
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: Contacts at Apple
To: Faculty@SU-SCORE.ARPA
cc: Fullerton@SU-SIERRA.ARPA
Message-ID: <12166807044.9.TAJNAI@SU-SCORE.ARPA>
We would like to recruit Apple into the Forum. Do any of you
have contacts at Apple?
Carolyn
-------
∂13-Dec-85 0936 MODICA@SU-SCORE.ARPA End Quarter Reports
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 09:36:17 PST
Date: Fri 13 Dec 85 09:30:41-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: End Quarter Reports
To: instructors@SU-SCORE.ARPA
Message-ID: <12166818598.26.MODICA@SU-SCORE.ARPA>
Hi again.
This is to remind you that I have to have ALL End Quarter Reports
by Tuesday December 17th (that's next Tuesday). I will walk
them to the Registrar's Office late in the afternoon, so as to
give everyone ample time to get them to me. You can drop them off
at my desk (MJH 030) or leave them in my mailbox (MODICA, top row),
and if at all possible try to avoid using the id mail to send them
to me.
Once again, don't take them to Victoria.
She does not want them.
I do.
Bye.
-Gina
-------
∂13-Dec-85 1019 MODICA@SU-SCORE.ARPA important correctio
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 10:18:54 PST
Date: Fri 13 Dec 85 10:14:40-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: important correctio
To: instructors@SU-SCORE.ARPA
Message-ID: <12166826606.26.MODICA@SU-SCORE.ARPA>
Hi.
The End Quarter Reports have to be at the Registrar's Office by NOON on
Tuesday. Sorry, my mistake.
Anyway, that means that I have to have them as early as possible Tuesday
morning.
Please remember this deadline.
And forget the other one.
It is wrong.
-Gina
-------
∂13-Dec-85 1141 ullman@su-aimvax.arpa oops again
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 11:41:19 PST
Received: by su-aimvax.arpa with Sendmail; Fri, 13 Dec 85 11:36:23 pst
Date: Fri, 13 Dec 85 11:36:23 pst
From: Jeff Ullman <ullman@diablo>
Subject: oops again
To: nail@diablo
Boy do I feel stupid. I *think* I now understand what Allen
was trying to say. As long as the function f←e is expressible
by a tableau, then the condition (ALL e) (f←e)* C← (g←e)*
is equivalent to (EXISTS i>1)(ALL e) f←e C← (g←e)↑i
[e stands for an arbitrary "database"]
I thought the quantification went the other way.
As a result, we can prove (ALL e) (f←e)* = (g←e)* implies (ALL e) f←e = g←e
as follows, in the case that (EXISTS e) f←e is containment free.
(EXISTS i,j>1)(ALL e) f←e C← (g←e)↑i and g←e C← (f←e)↑j
thus (ALL e) f←e C← (f←e)↑{ij}, violating the c.f. condition.
There may still be one nasty: in simple cases like the transitive
closure, the e for which f←e is containment-free is infinite;
there cannot be a finite such e. That may bother some people.
∂13-Dec-85 1422 ullman@su-aimvax.arpa papers received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 14:22:13 PST
Received: by su-aimvax.arpa with Sendmail; Fri, 13 Dec 85 14:14:17 pst
Date: Fri, 13 Dec 85 14:14:17 pst
From: Jeff Ullman <ullman@diablo>
Subject: papers received
To: nail@diablo
"A model and an architecture for relational knowledge base"
by H. Yokota and H. Itoh of ICOT
"Deductive database system based on unit resolution"
by Yokota, Itoh and K. Sakai
∂13-Dec-85 1441 LANSKY@SRI-AI.ARPA revised PLANLUNCH schedule
Received: from SRI-AI.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 14:41:48 PST
Date: Fri 13 Dec 85 14:36:54-PST
From: LANSKY@SRI-AI.ARPA
Subject: revised PLANLUNCH schedule
To: planlunch.dis: ;
cc: ladkin@KESTREL.ARPA
Due to various scheduling rearrangements, there will be NO MORE planlunches
this quarter. We will be startup up again in January, with the following
tentative schedule:
January 8 (Wed) : James Allen
January 15 (Wed): Marcel Schoppers
January 20 (Mon): Dave Smith
January 27 (Mon): Peter Ladkin
:
?
Once again, those of you who would like to give planlunch talks, please
contact me.
Happy Holidays,
Amy Lansky (LANSKY@SRI-AI)
-------
∂13-Dec-85 1609 @SU-SUSHI.ARPA,@SU-SCORE.ARPA:karp@ernie.berkeley.edu
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 16:09:14 PST
Received: from SU-SCORE.ARPA by SU-SUSHI.ARPA with TCP; Fri 13 Dec 85 16:03:13-PST
Received: from ucbvax.berkeley.edu by SU-SCORE.ARPA with TCP; Fri 13 Dec 85 15:40:46-PST
Received: by ucbvax.berkeley.edu (5.31/1.7)
id AA28415; Fri, 13 Dec 85 15:35:25 PST
Received: by ernie (5.31/5.16)
id AA12160; Fri, 13 Dec 85 14:20:20 PST
Date: Fri, 13 Dec 85 14:20:20 PST
From: karp@ernie.berkeley.edu (Richard Karp)
Message-Id: <8512132220.AA12160@ernie>
To: aflb.local@su-score.arpa, allmsgs@ernie.berkeley.edu,
csfaculty@ernie.berkeley.edu, csmsgs@ernie.berkeley.edu,
theory-b@ernie.berkeley.edu, theory-f@ernie.berkeley.edu
MATHEMATICAL SCIENCES RESEARCH INSTITUTE
1000 Centennial Drive, Berkeley, Ca. 94720 (415)642-0143
SEMINAR IN COMPLEXITY
Tuesday, December 17 2:00 MSRI Lecture Hall
Daniel D. Sleator "Tree Rotations, Dissections of Polyhedra and Hyperbolic
Geometry"
∂13-Dec-85 1804 @MIT-MC.ARPA:JF@SU-SUSHI.ARPA SDI Debate at Stanford, 12/19/85
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 18:04:02 PST
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 DEC 85 21:04:21 EST
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 13 Dec 85 20:59-EST
Received: from SU-SUSHI.ARPA by MIT-MC.ARPA 13 Dec 85 21:02:13 EST
Date: Fri 13 Dec 85 17:56:01-PST
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: SDI Debate at Stanford, 12/19/85
To: AILIST@SRI-AI.ARPA, ARMS-D@MIT-MC.ARPA, ARPANET-BBOARDS@MIT-MC.ARPA,
EVOLUTION@KESTREL.ARPA, MsgGroup@BRL.ARPA, NA@SU-SCORE.ARPA,
PHIL-SCI@MIT-MC.ARPA, POLI-SCI@RED.RUTGERS.EDU, PROLOG@SU-SCORE.ARPA
Message-ID: <12166910591.26.JF@SU-SUSHI.ARPA>
APOLOGIES TO THOSE WHOSE BBOARDS RECEIVED MULTIPLE COPIES OF THIS.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
``SDI: How Feasible, How Useful, How Robust?''
This will be a technical debate, covering both hardware and software aspects
of SDI.
Sponsor: Stanford Computer Science Department
Date: December 19, 1985
Time: 8:00 p.m.
Place: Terman Auditorium
Organizer: Barbara Simons, IBM-SJ
Moderator: Dr. Marvin L. Goldberger, President of Cal Tech.
Former member of President's Science Advisory Committee
and Consultant on Arms Control and International Security.
Panelists:
Advocates:
Professor Richard Lipton, Professor of Computer Science at Princeton
University, Current member of SDIO's Panel on Computing and Support of Battle
Management.
Major Simon Peter Warden, the Special Assistant to the Director of the SDIO
and Technical Advisor to the Nuclear and Space Arms Talk with the USSR
in Geneva.
Opponents:
Dr. Richard L. Garwin, IBM Fellow and Adjunct Professor of Physics at
Columbia University, Physicist and Defense Consultant.
Professor David Parnas, Lansdown Professor of Computer Science at the
University of Victoria, Former member of the SDI Organization's
Panel on Computing and Support of Battle Management.
-------
∂14-Dec-85 JF@SU-SUSHI.ARPA 14-Dec-85 JMC Sleator talk at SRC, Monday, 12/16/85, 2 p.m.
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 14:53:13 PST
Date: Sat 14 Dec 85 14:49:25-PST
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: Sleator talk at SRC, Monday, 12/16/85, 2 p.m.
To: aflb.all@SU-SUSHI.ARPA
cc: su-bboards@SU-SUSHI.ARPA
Message-ID: <12167138766.16.JF@SU-SUSHI.ARPA>
Monday, Dec. 16, 1985, DECSRC, 2:00 p.m.
Speaker: Dan Sleator, CMU
Title: "Tree Rotations, Dissections of Polyhedra and Hyperbolic Geometry"
Editorial Comment (jf):
If I've got this straight, Danny is going to
present his joint work with Tarjan and Thurston on the ``rotation distance''
between two trees, which is, vaguely, the number of local restructuring
operations needed to transform one tree into another. They extend previously
known combinatorial results to prove that 2m-6 in an upper bound on
the distance between a pair of m-node trees and then use hyperbolic
geometry to construct an infinite family of pairs for which this bound
is tight. This work provides a rare and beautiful example of the use of
continuous methods to resolve a long-standing open problem in discrete
mathematics, and I'm sure the talk will be entertaining and well worth your
time.
Please arrive at DECSRC, 130 Lytton Avenue, Palo Alto, at least 10 minutes
early so that you can be ``signed in''.
-------
jmc - Isn't that "Bud" Sleator?
∂14-Dec-85 1627 BRESNAN@SU-CSLI.ARPA interactions of morphology, syntax, and discourse
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 16:27:24 PST
Date: Sat 14 Dec 85 16:24:29-PST
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: interactions of morphology, syntax, and discourse
To: folks@SU-CSLI.ARPA
This Thursday, December 19, at 10:00 a.m., Jonni Kanerva will present
his analysis of pronominal incorporation in Finnish possessives,
which shows that syntactically functioning pronouns can occur
within the lexical morphology of words, a result with
far-reaching consequences for the organization of grammars. Everyone is
invited. Copies of the written version of the presentation are
available at the front desk at Ventura Hall.
---------------
A class of five morphemes in Finnish, traditionally called
possessive suffixes (henceforeward Px), raises interesting questions
about the relationship of morphological structure to syntactic
functions. Px's appear to be pronominal, anaphoric, or even
agreement-like elements that occur on nominals and nonfinite verbs
following case suffixes. They are important syntactically: among
other things, they occur as possessors of nouns and as subjects of
nonfinite clauses. The very importance of Px's in the syntax tempts
one to analyse them as syntactic units -- clitics -- that are joined
phonologically to host words, as two recent analyses have done.
Nonetheless, a number of facts in Finnish indicate that these
syntactic functions are born by truly morphological units --
suffixes -- rather than clitics.
I argue from phonological, morphological, and semantic evidence.
First, any allomorphy or phonological alternation in Finnish that is
sensitive to word boundaries treats the undisputed suffixes and the
Px's alike as being inside the word and treats a class of clitics as
being outside the word. Second, the occurrence of Px's is sometimes
dependent on the specific morphological structure of the stem. Third,
a large number of semantically idiosyncratic lexical items containing
Px's provide further support for a suffixal analysis of Px's, insofar
as suffixes are more susceptible to idiosyncratic lexicalization than
clitics. I argue next against the possibility that Px's are lexical
level clitics (i.e., clitics that attach to words at the morphological
level) by showing that it is quite costly to the theory of lexical
phonology to have a lexical level in Finnish that contains all of the
undisputed suffixes yet excludes the Px's; hence Px's must occupy the
same lexical level as other suffixes. Considering, then, all of the
evidence favoring a suffixal analysis for the Px's, especially the
morphological interactions between Px's and their stems, it is
extremely weak to set Px's apart from the other suffixes solely on
the basis of morpheme order. This indicates that the Px's are indeed
suffixes and therefore that a syntactic analysis of Px's should be
consistent with this finding.
--Jonni Kanerva
-------
-------
∂14-Dec-85 1633 ACUFF@SUMEX-AIM.ARPA Common Lisp Meeting Summary
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 16:33:46 PST
Date: Sat 14 Dec 85 16:31:55-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Common Lisp Meeting Summary
To: ksl-lispm@SUMEX-AIM.ARPA
Message-ID: <12167157426.54.ACUFF@SUMEX-AIM.ARPA>
I've sent a summary of the Common Lisp meeting held in Boston
recently to Common-Lisp@Sumex, so it will be part of bboard:common-lisp.txt
and can be read with "bboard common-lisp" from the Exec or MM on sumex.
-- Rich
-------
∂14-Dec-85 2249 vardi@su-aimvax.arpa Preliminary PODS program
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 22:48:53 PST
Received: by su-aimvax.arpa with Sendmail; Sat, 14 Dec 85 22:44:41 pst
Date: Sat, 14 Dec 85 22:44:41 pst
From: Moshe Vardi <vardi@diablo>
Subject: Preliminary PODS program
To: fagin@ibm-sj, nail@diablo
ACM SYMPOSIUM ON
PRINCIPLES OF DATABASE SYSTEMS
Cambridge, Massachusetts, March 24-26, 1986
Program
Session 1 Chaired by Avi Silberschatz, University of Texas at Austin
Magic Sets and Other Strange Ways To Implement Logic Programs
Francois Bancilhon (Microelectronics and Computer Technology Corporation)
David Maier (Oregon Graduate Center)
Yehoshua Sagiv (Stanford University)
Jeffrey D. Ullman (Stanford University)
Convergence of Sideways Query Evaluation
Foto Afrati (National Technical University of Athens)
Christos Papadimitriou (Stanford University)
George Papageorgiou (National Technical University of Athens)
Athena Roussou (National Technical University of Athens)
Yehoshua Sagiv (Stanford University)
Jeffrey D. Ullman (Stanford University)
On the Implementation of a Simple Class of Logic Queries
Domenico Sacca (Microelectronics and Computer Technology Corporation)
Carlo Zaniolo (Microelectronics and Computer Technology Corporation)
Session 2 Chaired by Hector Garcia-Molina, Princeton University
A Theoretical Foundation of Multi-Level Concurrency Control
Gerhard Weikum (Technische Hochschule Darmstadt)
Deleting Completed Transactions
Thanasis Hadzilacos (National Technical University of Athens)
Mihalis Yannakakis (AT&T Bell Labs)
Safety of Non-well-locked Transaction Systems
Jianwen Su (University of Lowell)
Session 3 Chaired by Meral Ozsoyoglu, Case Western Reserve University
A Calculus for Complex Objects
Francois Bancilhon (Microelectronics and Computer Technology Corporation)
Setras Khoshafian (Microelectronics and Computer Technology Corporation)
Some Classes of Multilevel Relational Structures
Dirk Van Gucht (Indiana University at Bloomington)
Patrick C. Fischer (Vanderbilt University)
Weak Temporal Relations
Shashi K. Gadia (Texas Tech University)
Session 4 Chaired by Per-Ake Larson, University of Waterloo
Rearranging Data to Maximize the Efficiency of Compression
Frank Olken (Lawrence Berkeley Laboratory)
Order Preserving Linear Hashing Using Dynamic Key Statistics
John T. Robinson (Thomas J. Watson Research Center)
Balanced Multidimensional Extendible Hash Tree
Ekow J. Otoo (Carleton University)
Session 5 Chaired by Moshe Vardi, IBM Research Lab
Negation by Failure in First-Order Queries
Shamim A. Naqvi (AT&T Bell Labs)
Positivism vs. Minimalism in Deductive Databases
Nicole Bidiot (I.N.R.I.A.)
Richard Hull (University of Southern California)
The Extended Closed World Assumption and Its Relationship to Parallel
Circumscription
M. Gelfond (University of Texas at El Paso)
H. Przymusinska (University of Texas at El Paso)
T. Przymusinska (University of Texas at El Paso)
Session 6 Chaired by Alberto Mendelzon, University of Toronto
On the Properties and Characterization of Connection-trap-free Schemes
Edward P. F. Chan (University of Alberta)
One Flavor Assumption and Gamma-acyclicity for Universal Relation Views
J. Biskup (Universitat Dortmund)
H.H. Bruggeman (Universitat Dortmund)
L. Schnetgoke (Universitat Dortmund)
M. Kramer (FernUniversitat Hagen)
The Equivalence of Tree Projections and Solving Queries
Yehoshua Sagiv (Stanford University)
Oded Shmueli (Technion-Israel Institute of Technology)
Session 7 Chaired by Ed Sciore, Boston University
Unifying Functional and Multivalued Dependencies for Relational Database
Design
Meral Ozsoyoglu (Case Western Reserve University)
Li-Yan Yuan (Case Western Reserve University)
On Finite FD-Acyclicity
Yehoshua Sagiv (Stanford University)
Oded Shmueli (Technion-Israel Institute of Technology)
Alpha-acyclic Decompositions of Relational Database Schemes
Detlev Ruland (Universitat Wurzburg)
Dietmar Seipel (Universitat Wurzburg)
Session 8 Chaired by Ronald Fagin, IBM Research Lab
Constant Time Maintenance or the Triumph of the fd
Marc Graham (Georgia Institute of Technology)
Ke Wang (Georgia Institute of Technology)
Test Data for Relational Queries
Heikki Mannila (University of Helsinki)
Kari-Jouko Raiha (University of Tampere)
A Model-Theoretic Approach to Updating Logical Databases
Marianne Winslett (Stanford University)
Session 9 Chaired by Paris Kanellakis, Brown University
Properties of Transactional Schemas
Serge Abiteboul (I.N.R.I.A.)
Victor Vianu (University of California, San Diego)
Availability in Partitioned Replicated Databases
Amr El Abbadi (Cornell University)
Sam Toueg (Cornell University)
Session 10 Chaired by Francois Bancilhon, Microelectronics and Computer
Technology Corporation
Data Independent Recursion in Deductive Databases
Jeff Naughton (Stanford University)
Incomplete Information and Default Reasoning
Moshe Vardi (IBM Research Lab)
Parallel Evalution of Recursive Rule Queries
S. Cosmadakis (IBM Thomas J. Watson Research Center)
Paris Kanellakis (Brown University)
-------
∂15-Dec-85 0948 DELAGI@SUMEX-AIM.ARPA [HAL%MIT-OZ@MIT-MC.ARPA: intro computer science course at Brandeis]
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 09:48:18 PST
Date: Sun 15 Dec 85 09:47:48-PST
From: Bruce Delagi <DELAGI@SUMEX-AIM.ARPA>
Subject: [HAL%MIT-OZ@MIT-MC.ARPA: intro computer science course at Brandeis]
To: aap@SUMEX-AIM.ARPA
Message-ID: <12167346003.15.DELAGI@SUMEX-AIM.ARPA>
fyi......./b
---------------
Return-Path: <@MIT-MC.ARPA:HAL@MIT-OZ>
Received: from MIT-MC.ARPA by SUMEX-AIM.ARPA with TCP; Sat 14 Dec 85 06:04:39-PST
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 14 DEC 85 08:25:33 EST
Date: Sat, 14 Dec 1985 08:22 EST
Message-ID: <HAL.12167035500.BABYL@MIT-OZ>
From: HAL%MIT-OZ@MIT-MC.ARPA
To: scheme@MIT-MC.ARPA
Subject: intro computer science course at Brandeis
This past semester, Brandeis University changed its introductory
computer science subject to use "Structure and Interpretation of
Computer Programs" and Scheme (running on Texas Instruments PCs).
The following essay is by Harry Mairson, who was in charge of the
subject.
\magnification = 1200
\centerline
{\bf Structure and Interpretation of Computer Programs}
\centerline{Autumn Semester, 1985}
\medskip
\centerline{\sl by Harry Mairson}
\bigskip
\bigskip
\parskip = 5pt plus1pt minus .5pt
This year, the Brandeis computer science department introduced a new
introductory course for its prospective majors. {\sl Structure and
Interpretation of Computer Programs}, a textbook and novel curriculum
under development at MIT for several years, replaced a standard course
teaching Pascal and modular programming. I taught the course in
cooperation with Harold Abelson, one of the MIT professors who
developed the curriculum. As the course comes to a conclusion this
term, I would like to make a few comments about its contents, and why
I believe it has been and will continue to be a success at Brandeis.
First of all, ``Structure and Interpretation of Computer Programs'' is
a sophisticated and high-powered course, presenting to students with
no presumed background in computer science an intensive introduction
to the subject of computation. Among the subjects presented in this
course are: induction and recursion, lambda calculus, actor models,
tail recursion, orders of growth, abstraction mechanisms, data-driven
and procedure-driven (i.e., ``message passing'') computation, data
structures, substitution and environment models of computation, stream
processing, applicative- and normal-order evaluation, how interpreters
and compilers work, and logic programming. All this as an {\sl
introduction} to computer science! I did not learn about many of these
subjects until I was in graduate school, and some I learned only while
teaching this innovative course.
Such an ambitious curriculum cannot succeed without a substantial
commitment of resources from both students and the University. Students
worked 15 to 20 hours a week on this course, sometimes more. The
computer science department bought 18 Texas Instruments Professional
Computers, with the latest version of the Scheme programming language that
was practically hot off the press; there were fewer than three students per
personal computer. Hal Abelson gave a two-hour master class each week.
I gave two one-hour recitation lectures, plus interminable tutorials.
(I had no fixed office hours, tried to be in as much as possible, and
students badgered me with questions constantly, sometimes until early
morning...) Three teaching assistants, Brandeis graduate students
Larry Bookman, Xiru Zhang, and Brandeis senior Moises Lejter ran
one-hour tutorials every week in groups of four to five students,
and worked as tutors in the laboratory. They were unflagging in their
dedication and patience. In addition, they were joined by three MIT
undergraduates, David Alcocer, Jos\'e Capo, and Scott Heeschen, providing
on-the-spot counseling and tutoring in the midst of programming crises.
The MIT students were great, but as I joked to them on their arrival,
``I'm delighted to have you help, and I can't wait to throw you out.''
Next year, Brandeis undergraduates will take their places.
The kids in the class knew every resource we could conceivably provide
them was there. Given that total commitment, they showed beyond any
doubt their own commitment and willingness to work real hard and absorb
the material.
This course has something new and profound to say about computation and
learning. With no time wasted, it immediately plunges into a discusssion
of the {\sl semantics} of computation, and treats almost peripherally
the questions of syntax. The importance of this approach can best be
explained by considering the difference between learning a foreign
language (say, French) and a computer language.
Before learning my first word of French, I already understood the semantics
of the language, since ``meaning'' means the same thing in English as it
does in French, despite any Gallic claims to the contrary: the French
talk about tables, chairs, families, taxes, good food, vacations; they use
the same verbs, adjectives, and adverbs as we do, and essentially the same
notions of time. So ``learning French'' meant learning a new grammar to
express the same ideas and thoughts I already knew how to express
in English.
The same cannot be said for learning a computer language, because there the
overriding questions of the {\sl d\'ebutant} are: what is the computer
doing, what {\sl can} it do, and what does my program {\sl mean?}
The grammar of any programming language is far simpler than that of
French; given enough compulsiveness, anyone can learn to make sure that all
the semicolons are in the right place, that for every {\tt BEGIN} there
is an {\tt END}, that left and right parentheses match. These grammatical
rules are annoying, but not conceptually deep.
It happens that this course is taught using the Scheme language, a dialect
of a more famous programming language called Lisp. But as the authors of
the text write, ``After a short time we forget about syntactic details
of the language (because there are none), and get on with the real issues.''
The Scheme language is used because it expresses easily a wide range of
computational processes, but these processes, and not the language itself,
are the centerpiece of this course.
Such an emphasis, as well as many other aspects of the course, is in
the best tradition of liberal education. The course is not simply a
compendium of ``current'' tricks of the programming trade that will
doubtless change in the next six months, but presents a foundation from
which today's and tomorrow's issues and controversies in computer science
can be understood and put into perspective. I expect this course will
teach students to think for themselves.
Computer science often attracts the ire of specialists in other academic
fields, principally physicists and mathematicians, but philosophers and
just about everyone else too, because it seems so narrow and self-referential
that it doesn't relate to other fields of study. This course goes a long
way to healing the wounds of that misconception, as well as teaching
students a healthy appreciation for the respective fields that are
not simply the ancestors of computer science, but its much needed partners
in the pursuit of knowledge and understanding. That means I want my
students to take lots of math, physics, and philosophy courses, and know
what these subjects are about!
For example, no discussion of the meaning of language can take place outside
the tradition of philosophy and its profound contribution to the understanding
of language. In the Scheme language, for example, the meaning of a simple
expression like {\tt (cons x y)} can be explored on many levels, none of them
artificial. The mechanism used by the computer to evaluate this expression
can be implemented in several ways that are substantially different:
{\tt (cons x y)} could be interpreted as a memory structure, an integer,
or a procedural abstraction. On the other hand, the expression has
precise meaning simply in its fixed use with respect to the other
constructs of the Scheme language.
I spent one lecture describing these two radically different points of
view, showing how the former view of ``meaning as implementation'' is the
direct descendant of logical atomism in the tradition of Bertrand Russell
and his followers, while the latter idea of ``meaning as use'' is a
natural consequence of the philosophy of language as proposed in the
later writings of Ludwig Wittgenstein. Similarly, in a discussion of the
so-called ``environment model'' of computation, the subject of denotation
is explored: we understand how classical problems of referential
transparency in language are resolved, and how conceptions of meaning and
time relate to each other. The semantics of computation becomes a
controlled laboratory where we can discover more about the complex
relationship of meaning and language.
Apart from the usual arithmetic programming examples, the course draws on
problems and examples from mathematics and physics. In one two-week problem
set, for example, the students implemented a video game called ``Lunar
Lander,'' where a spaceship with a fixed amount of fuel must be landed
under a gravitational force without crashing. In doing so, they experimented
with a variety of landing strategies. The principal goal of the problem set
is to teach the students how to use something called lambda expressions,
a programming language construct borrowed from mathematical logic. But the
problem set also makes the students think about models of physical reality,
where computation is not simply {\sl sui generis} but an analog of the
physical world. They implemented an optimal fuel-efficient landing
strategy, and I made them understand the ideas of calculus and elementary
physics that justifies calling the strategy optimal.
In other material developed in the course, methods of data structuring are
used to implement symbolic differentiation as in the differential calculus.
Stream processing provides a method for understanding integration, and
shows how the arithmetic of infinite power series can be automated. The
connections of these methods to the Macsyma system of ``symbolic
mathematics,'' a computer system of great use to researchers in science
and mathematics, are no mere coincidences.
Finally and most profoundly, the material presented in this course teaches
a wonder and respect for computation. It is true, as often repeated in that
hackneyed phrase, that computers only do what we tell them to. Stated
otherwise, a computational process evolves in a deterministic fashion from
an initial state, subject to fixed and mechanical constraints on the nature
of that evolution. But the potential richness, depth, and variety of that
evolution, as this course teaches, is truly mind-boggling. In the
introduction to their book, Harold Abelson and his co-author Gerald Jay
Sussman, also of MIT, write the following:
\bigskip
\item{}
We are about to study the idea of a {\sl computational process.}
Computational processes are abstract beings that inhabit computers. As
they evolve, processes manipulate other abstract things called {\sl data.}
The evolution of a process is directed by a pattern of rules called a
{\sl program.} People create programs to direct processes. In effect,
we conjure the spirits of the computer with our spells.
\item{}
A computational process is indeed much like a sorcerer's idea of a spirit.
It cannot be seen or touched. It is not composed of matter at all.
However, it is very real. It can perform intellectual work. It can
answer questions. It can affect the world by disbursing money at a bank
or by controlling a robot arm in a factory. The programs we use to conjure
processes are like a sorcerer's spells. They are carefully composed from
symbolic expressions in arcane and esoteric {\sl programming languages}
that prescribe the tasks that we want our processes to perform.
\item{}
A computational process, in a correctly working computer, executes programs
precisely and accurately. Thus, like the sorcerer's apprentice, the
novice programmer must learn to understand and to anticipate the
consequences of his conjuring.
\bigskip
In the same way that a biochemist marvels at DNA as a code that directs
the amazing growth and development of living organisms, I marvel as I watch
computer programs provide the code for the creation and interaction of
Abelson and Sussman's computational ``spirits.'' Just as
a chemist sees the elementary chemical building blocks
of nature interact, combine,
and recombine as she pours solutions together, the computer scientist
sees the rich and seemingly unpredictible interaction of computational
processes as a result of her procedural incantations.
For all those who have looked askance at the existence of computer science
in the university, Abelson and Sussman have written, ``Underlying our
approach to this subject is our conviction that `computer science' is
not a science and its significance has little to do with computers.
The computer revolution is a revolution in the way we think and in the way
we express what we think.''
I believe that nothing could be more exciting or more important at a
university than to understand the way we think and how we express those
thoughts. This new introductory course comes face-to-face with these profound
issues, and brings its students into the heart of the consequent
intellectual debate, sometimes pushing them to within striking distance
of the frontiers of research. I believe it will provide them with tools
to strike out on frontiers of their own, frontiers of personal discovery,
creativity, understanding and synthesizing of knowledge, driven on by
the powerful metaphors that the study of computational processes provide,
and by the personal intellectual success that this course provides them.
This new course demands a great commitment from its students and
teaching staff. Students have five official ``contact hours'' per
week with the teaching staff, and many more on an informal basis.
Because of that great contact, I believe that this course has another
thing to say that is also profound, though perhaps peripheral to the
issues of computation. The University is a place for teaching and
learning, not simply for the transmission of information. Teaching
and learning reinforce the respect, encouragement, and love that any
society or university needs to flourish. I hope this class says
loudly and clearly that students have a place in the crucial function
of this University, not as passive receivers of knowledge that spouts
from the end of a pedagogical assembly line, but as partners in an
important dialogue that defines what the University is.
I want the students in this class to have learned two things. First,
how much there is that they don't know. And second, that they can
learn anything they want. I hope that they will never forget the
former, and always be inspired by the latter. Every conceivable thing
was done in this course to provide a fertile and inspiring environment
for learning and discovery. What could students possibly do under
such circumstances but mature, grow, and learn?
The lesson for the teaching staff in this course is not so different.
While Newton said he saw further because he stood on the shoulders of
giants, I have always preferred Nietzsche's remark that a teacher is
poorly repaid if one only remains a student.
What a tremendous debt we teachers owe to those who nurtured us! We
honor those who taught us by nurturing students, and the way we
express that nurturing is to teach students to grow and think for
themselves, so they don't need us any longer. A friend of mine who is
a physician once said that the responsibility of a doctor is to love
your patients. I believe above all that the responsibility of a
teacher is to love your students, to show them what is known, and to
inspire them to confront the unknown. The territory is vast, and
because computer science is still so new, largely unexplored. The
rewards are great for those who simply press forward.
\bye
-------
∂15-Dec-85 1854 PARSYM-Request@SUMEX-AIM.ARPA PARSYM Digest V1 #46
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 18:54:02 PST
Date: 15 Dec 85 1838-PST
From: Moderator Byron Davies <PARSYM-REQUEST@SUMEX-AIM.ARPA>
Reply-to: PARSYM@SUMEX-AIM.ARPA
Subject: PARSYM Digest V1 #46
To: PARSYM@SUMEX-AIM.ARPA
PARSYM Digest Monday, 16 Dec 1985 Volume 1 : Issue 46
Today's Topics:
SEAI Parallel Computing Survey
Seminar: A Parallel Algorithm for Depth First Search (MIT)
----------------------------------------------------------------------
Date: Thursday, 12 December 1985 09:40-PST
From: Carolyn Talcott <CLT at SU-AI.ARPA>
Subject: SEAI Parallel Computing Survey
I called the SEAI folks and got the following additional information:
It was compiled by R. Miller by asking `experts in the field'
(of which he is not one).
It is current - last survey results received in August 85
Length = 123 pages
Can get 15% discount for university use
It can be returned within 30 days for full refund
[Has anybody on PARSYM purchased the SEAI survey? Are there any
surprises in it? -- BD]
------------------------------
Date: 12/11/85 10:50:41
From: LISA at MIT-MC.ARPA
Re: Talk by Anderson
[Forwarded from the MIT-MC BBoard by SASW@MIT-MC]
DATE: Friday, December 13, 1985
TIME: 1:00.....Lecture
PLACE: NE43 - 512A
"A PARALLEL ALGORITHM FOR DEPTH FIRST SEARCH"
Richard Anderson
MSRI
Abstract:
A new parallel algorithm for constructing a depth first search tree in an
undirected graph will be described. The algorithm is a P-RAM algorithm and
uses several probabilistic algorithms as sub-routines.
The run time of the algorithm is 2 sq.rt. log n. This makes it an almost RNC
eps.
algorithm, since the run time is less than n for any eps.>0.
The standard sequential algorithm for depth first search can be shown to be
"inherently sequential", so this shows that substantial speed up for depth
first search is possible when a different approach is taken.
David Shmoys
Host
------------------------------
End of PARSYM Digest
********************
∂16-Dec-85 0844 RICHARDSON@SU-SCORE.ARPA Near West Campus
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 08:44:13 PST
Date: Mon 16 Dec 85 08:41:11-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Near West Campus
To: ac@SU-SCORE.ARPA, srstaff@SU-SCORE.ARPA
Message-ID: <12167596021.20.RICHARDSON@SU-SCORE.ARPA>
Today is the Near West Campus review which will take place in Durand 450
from 4:00 - 6:00 with Dean Gibbons in attendance.
-------
∂16-Dec-85 1057 DELANEY@SUMEX-AIM.ARPA Re: [HAL%MIT-OZ@MIT-MC.ARPA: intro computer science course at Brandeis]
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 10:55:16 PST
Date: Mon 16 Dec 85 10:54:29-PST
From: John R Delaney <DELANEY@SUMEX-AIM.ARPA>
Subject: Re: [HAL%MIT-OZ@MIT-MC.ARPA: intro computer science course at Brandeis]
To: DELAGI@SUMEX-AIM.ARPA
cc: aap@SUMEX-AIM.ARPA, DELANEY@SUMEX-AIM.ARPA
In-Reply-To: <12167346003.15.DELAGI@SUMEX-AIM.ARPA>
Message-ID: <12167620285.57.DELANEY@SUMEX-AIM.ARPA>
Quite inspirational, but what did the students who had to spend 15 to 20 or
more hours a week feel about the course? How much did they actually learn
from this course? Did they have time left to learn anything in the other
courses they were taking? I would like to hear the rest of the story some
day.
John (the cynic)
-------
∂16-Dec-85 1151 DIKRAN@SU-CSLI.ARPA New CSLI Informal Notes
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 11:51:34 PST
Date: Mon 16 Dec 85 11:45:44-PST
From: Dikran Karagueuzian <DIKRAN@SU-CSLI.ARPA>
Subject: New CSLI Informal Notes
To: folks@SU-CSLI.ARPA
CSLI Informal Notes
Three new CSLI Informal Notes have been published recently.
Copies may be obtained from Suzi Parker in Ventura Hall. The
Notes are
A Weak Logic of Knowledge and Belief: Epistemic
and Doxastic Logic for the Yuppie Generation
by David Israel (No. IN-CSLI-3),
Analogy
by Todd Davies (No. IN-CSLI-4),
Left-associative Grammar and the Parser NEWCAT
by Roland Hausser (No. IN-CSLI-5).
-------
∂16-Dec-85 1528 MODICA@SU-SCORE.ARPA Grades
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 15:27:46 PST
Date: Mon 16 Dec 85 15:23:05-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: Grades
To: instructors@SU-SCORE.ARPA
Message-ID: <12167669184.24.MODICA@SU-SCORE.ARPA>
This is very important!!!!!
I need your end quarter reports by 11:00 am tomorrow, so that I can
sort through them and get them to the registrar's by noon.
Once again, you can leave them on my desk or in my mail box on the
second floor.
Thanks.
-Gina
-------
∂16-Dec-85 1614 BRESNAN@SU-CSLI.ARPA talk by Fassi Fehri
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 16:12:28 PST
Mail-From: BRESNAN created at 16-Dec-85 11:19:11
Date: Mon 16 Dec 85 11:19:11-PST
From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
Subject: talk by Fassi Fehri
To: linguists@SU-CSLI.ARPA
ReSent-Date: Mon 16 Dec 85 16:08:29-PST
ReSent-From: Joan Bresnan <BRESNAN@SU-CSLI.ARPA>
ReSent-To: folks@SU-CSLI.ARPA
This Wednesday, December 16 at 10:00 a.m. Fassi Fehri will
present his work on agreement in Arabic in the Ventura Conference
Room.
Agreement in Arabic, Binding and Extended Coherence
We provide a fragment of a conceptual framework in which agreement
phenomena can be naturally characterised in correlation with grammatical
functions, and the appropriate well-formedness constraints on functional
structres would have as an effect to rule out agreement relations that
are unlikely to occur in natural languages. More specifically, we assume
a taxonomy of grammatical functions distinguishing three classes: lexical
( = L) and nuclear ( = N) GFs ( Subj, Obj, Obl, ...), non-L but N GFs
( Adjunct, Modifier ), and non-L non-N ( Top, Foc ... ). Non-L non-N
grammatical functions are some times called discourse functions or DFs.
We argue that Coherence, whose initial essential role in KB was to ensure
the duplication in the syntax of L-government relations, should be redefined
to extend to non-L N as well as non-L non-N grammatical functions.
We furthermore argue for a typology of agreement distinguishing 'grammatical'
agreement from 'anaphoric' agreement. GAgr is with L GFs, AAgr with non-L
Gfs. Our proposal is that what appears to be an anaphoric agreement marker
is in fact an incorporated pronoun. The different types of agreement fall
out as effects of our Extended Coherence Condition plus other independently
motivated well-formedness conditions on functional structures.
-------
-------
∂16-Dec-85 1637 ullman@su-aimvax.arpa Request for open problems
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 16:33:48 PST
Received: by su-aimvax.arpa with Sendmail; Mon, 16 Dec 85 16:25:34 pst
Date: Mon, 16 Dec 85 16:25:34 pst
From: Jeff Ullman <ullman@diablo>
Subject: Request for open problems
To: nail@diablo
I got a letter from Jan Paredaens asking for a list of
open problems in the area of database theory, for publication
in EATCS. If anybody has some suggestions, I'll be happy to
forward them, or you can write to Jan at:
Universitaire Instelling Antwerpen
Departement Wiskunde en Informatica
Universiteitsplein 1 B-2610 Wilrijk
BELGIUM
∂17-Dec-85 0759 CHOMICKI@RED.RUTGERS.EDU recent debate on f*=g* and containment-free functions
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 07:59:05 PST
Received: from RED.RUTGERS.EDU by su-aimvax.arpa with Sendmail; Tue, 17 Dec 85 07:54:37 pst
Date: 17 Dec 85 10:54:12 EST
From: Jan Chomicki <CHOMICKI@RED.RUTGERS.EDU>
Subject: recent debate on f*=g* and containment-free functions
To: nail@SU-AIMVAX.ARPA
Message-Id: <12167849611.74.CHOMICKI@RED.RUTGERS.EDU>
I happened to follow the last debate documented on NAIL and I have some
problems with putting the results mentioned there together.
1. The fact:
(*) (ALL e) (f←e)* C← (g←e)* iff (EXISTS i>1) (ALL e) f←e C←(g←e)↑i
implies with g←e=f←e :
(EXISTS i>1) (ALL e) f←e C← (f←e)↑i
which implies that there are no containment-free functions satisfying (*).
Or am I missing something?
2. That makes
sense as strongly typed rules (where all the variables are typed)
satisfy (*) and none of them is containment-free.
3.It is not quite clear how to prove (*) for larger classes of rules
and exactly when it holds. (*) does not hold for the non-linear
transitive closure:
t(X,Y) :- t(X,Z) & t(Z,Y)
Again take f←e=g←e, although the database e does not matter here.
4.Non-linear transitive closure is containment-free.
Jan Chomicki
Dept.of Computer Science
Rutgers University
New Brunswick, NJ 08903
-------
∂17-Dec-85 1153 MODICA@SU-SCORE.ARPA grades
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 11:50:57 PST
Date: Tue 17 Dec 85 11:38:11-PST
From: Gina Modica <MODICA@SU-SCORE.ARPA>
Subject: grades
To: instructors@SU-SCORE.ARPA
Message-ID: <12167890385.24.MODICA@SU-SCORE.ARPA>
I you are not going to be able to hand in your grades on time,
please be sure and post grades so that students can see them.
The reason for this is that the registrar will give them all an
asterix (since grades were not on time), and unless they can find
the grades, they will come to me or you in a panick.
Thank You.
-Gina
-------
∂17-Dec-85 1416 DAVIES@SUMEX-AIM.ARPA Wednesday Meeting
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 14:16:11 PST
Date: Tue, 17 Dec 1985 13:57 PST
Message-ID: <DAVIES.12167915816.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: Wednesday Meeting
cc: Davies@SUMEX-AIM.ARPA
There will be a meeting tomorrow at 9:30 am to continue the discussion
of TINA.
-- Byron
∂17-Dec-85 1600 SCHMIDT@SUMEX-AIM.ARPA Alice's Lisp Machine
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 16:00:48 PST
Date: Tue 17 Dec 85 15:57:27-PST
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Alice's Lisp Machine
To: KSL-LispM@SUMEX-AIM.ARPA, KSL-Dolphins@SUMEX-AIM.ARPA
Message-ID: <12167937584.12.SCHMIDT@SUMEX-AIM.ARPA>
There's a 16243 byte cover of "Alice's Restaurant" set in the
MIT-AI/LISPM world that's posted as AIList Digest V3 #187. It's
awfully long, but I found it amusing enough to read all the way
through. --Christopher
-------
∂17-Dec-85 1601 EMMA@SU-CSLI.ARPA Newsletter
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 16:01:15 PST
Date: Tue 17 Dec 85 15:55:32-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter
To: folks@SU-CSLI.ARPA
Tel: 497-3479
Tomorrow's newsletter is the last for the year and should contain
announcements for all events upto and including Friday, January 10.
Please remember that the deadline for submission is tomorrow (December
18) at noon.
Many thanks,
Emma
-------
∂17-Dec-85 2126 ACUFF@SUMEX-AIM.ARPA I'll be away 23-Dec-85 to 6-Jan-86
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 17:05:09 PST
Date: Tue 17 Dec 85 17:03:37-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: I'll be away 23-Dec-85 to 6-Jan-86
To: sbARNES@SUMEX-AIM.ARPA, JORDAN@SUMEX-AIM.ARPA, ksl-lispm@SUMEX-AIM.ARPA,
ssrg-systems-staff@SUMEX-AIM.ARPA
Message-ID: <12167949628.56.ACUFF@SUMEX-AIM.ARPA>
I'll be gone over Christmas and New Years. I'll still read my
mail, so feel free to contact me that way. If an emergency comes up,
please contact James Rice if a Symbolics or TI machine is down, or an
SSRG Systems Staff person if there is a power or air conditioning
problem.
-- Rich
-------
∂17-Dec-85 2154 FEHRI@SU-CSLI.ARPA
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:27:50 PST
Date: Tue 17 Dec 85 20:13:15-PST
From: Fassi fehri <FEHRI@SU-CSLI.ARPA>
To: folks@SU-CSLI.ARPA
Has anyone seen the counter for the Xerox machine?
-------
∂17-Dec-85 2206 ullman@su-aimvax.arpa messages to nail
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:54:58 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 17 Dec 85 17:04:01 pst
Date: Tue, 17 Dec 85 17:04:01 pst
From: Jeff Ullman <ullman@diablo>
Subject: messages to nail
To: nail@diablo
I know there are many people on the nail list who are not
at Stanford. You may not know that you can mail to the
whole list by sending to nail@diablo.
(diablo is an arpanet host, if your mail system cares)
If you are curious or worried who is on the list, you
can mail to mailer@diablo a message with SUBJECT list nail
and no body. You must then do the same with subject list nail2
because for technical reasons we had to divide the list in two.
---Jeff Ullman
∂17-Dec-85 2206 @SU-CSLI.ARPA:PENTLAND@SRI-AI.ARPA MACHINES LEARNING TO TALK...
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:28:13 PST
Received: from SRI-AI.ARPA by SU-CSLI.ARPA with TCP; Tue 17 Dec 85 21:00:19-PST
Date: Tue 17 Dec 85 21:01:13-PST
From: PENTLAND@SRI-AI.ARPA
Subject: MACHINES LEARNING TO TALK...
To: folks@SU-CSLI.ARPA
a very highly recommended talk about machines learning
phonological rules --- automatically, from a limited corpus.
A special seminar in place of Pixels and Predicates:
NETTALK: Teaching a Massively-Parallel Network to Talk
Who: Terrence J. Sejnowski, Johns Hopkins
Where: CSLI trailers
When: 1:00pm - Wednesday, December 18, 1985
Abstract:
Text to speech is a difficult problem for rule-based systems
because English pronunciation is highly context dependent and there are
many exceptions to phonological rules. An alternative knowledge
representation for correspondences between letters and phonemes will be
described in which rules and exceptions are treated uniformly and can
be determined with a learning algorithm in a connectionist model. The
architecture is a layered network of 400 simple processing units with
9,000 weights on the connections between the units. The training
corpus is continuous informal speech transcribed from tape recordings.
Following training on 1000 words from this corpus the network can
generalize to novel text. Even though this network was not designed to
mimic human learning, the development of the network in some respects
resembles the early stages in human language acquisition. Following
damage of the network by either removal of units or addition of random
values to the weights the performance of the network degraded
gracefully. Issues which will be addressed include scaling of the
learning algorithm with the size of the problem, robustness of
learning to predicate order of the problem, and universality of
learning in connectionist models.
-------
∂17-Dec-85 2208 ullman@su-aimvax.arpa tomorrow's meeting
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:56:48 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 17 Dec 85 17:09:10 pst
Date: Tue, 17 Dec 85 17:09:10 pst
From: Jeff Ullman <ullman@diablo>
Subject: tomorrow's meeting
To: nail@diablo
I'm going to try to lead a discussion of how we build on
what Kathy has done to actually write some capture rules.
(sorry for that split infinitive)
With luck, I'll have completed my roadmap by tomorrow
and can distribute it. If not, I'll whine in public and hope
Kathy can bail me out.
There may be some other points of interest as well.
Allen has just shown me a neat NC proof for certain hard-looking
rules, and we might want to go over the hash that I made of
the "containment-free" business.
---Jeff
∂17-Dec-85 2214 ullman@su-aimvax.arpa addressing the nail list
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:52:00 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 17 Dec 85 20:18:13 pst
Date: Tue, 17 Dec 85 20:18:13 pst
From: Jeff Ullman <ullman@diablo>
Subject: addressing the nail list
To: nail@diablo
Arthur Keller informs me that the "official" name of diablo
in ARPA addressing tables is su-aimvax, and that you can't be guaranteed
of reaching the nail list (or me for that matter) unless you
use that host name.
∂17-Dec-85 2215 ullman@su-aimvax.arpa paper received
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:53:19 PST
Received: by su-aimvax.arpa with Sendmail; Tue, 17 Dec 85 17:10:00 pst
Date: Tue, 17 Dec 85 17:10:00 pst
From: Jeff Ullman <ullman@diablo>
Subject: paper received
To: nail@diablo
"An Algebraic Approach to Recursive Inference"
by Y. Ioannidis and E. Wong, UCB/ERL M85/93, Berkeley.
∂17-Dec-85 2300 ark@SALLY.UTEXAS.EDU Re: addressing the nail list
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 23:00:25 PST
Received: from sally.UTEXAS.EDU by su-aimvax.arpa with Sendmail; Tue, 17 Dec 85 22:57:06 pst
Date: Wed, 18 Dec 85 00:48:06 cst
From: ark@SALLY.UTEXAS.EDU (Arthur M. Keller)
Posted-Date: Wed, 18 Dec 85 00:48:06 cst
Message-Id: <8512180648.AA08361@sally.UTEXAS.EDU>
Received: by sally.UTEXAS.EDU (4.22/4.22)
id AA08361; Wed, 18 Dec 85 00:48:06 cst
To: ullman@SU-AIMVAX.ARPA
Subject: Re: addressing the nail list
Cc: nail@SU-AIMVAX.ARPA
Actually, the official name of diablo is "SU-AIMVAX.ARPA" until
Stanford adopts the new domain addressing standard. Some hosts accept
"diablo" and "SU-AIMVAX" but not all do. "nail@SU-AIMVAX.ARPA" is the
current best way to reach the nail! mailing list and
"ullman@SU-AIMVAX.ARPA" is a good way to reach Jeff Ullman. Note that
SU-AIMVAX.ARPA insists on using "diablo" in its mail headers (in
violation of the relevant DDN standard), which may cause confusion on
replies from sites not accepting accepting the nickname "diablo".
Arthur
∂18-Dec-85 1302 YAMARONE@SU-CSLI.ARPA extra sandwiches
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 13:01:06 PST
Date: Wed 18 Dec 85 12:57:25-PST
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: extra sandwiches
To: folks@SU-CSLI.ARPA
Two turkey on light ryes left.....only $2.50.....
Listen to your stomach...come and get them while the last!
the Ventura Sandwich Corp.
-------
∂18-Dec-85 1428 EPPLEY@SU-SCORE.ARPA Day Off
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 14:28:17 PST
Date: Wed 18 Dec 85 14:13:29-PST
From: LaDonna Eppley <EPPLEY@SU-SCORE.ARPA>
Subject: Day Off
To: CSD@SU-SCORE.ARPA
Message-ID: <12168180800.25.EPPLEY@SU-SCORE.ARPA>
The University has officially given all staff Monday, December 23, as
a paid holiday. This is, in addition, to December 24 and 25. Have a
wonderful holiday.
LaDonna
-------
∂18-Dec-85 1537 TOM@SU-SCORE.ARPA Re: Day Off
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 15:37:14 PST
Date: Wed 18 Dec 85 15:27:34-PST
From: Thomas Dienstbier <TOM@SU-SCORE.ARPA>
Subject: Re: Day Off
To: EPPLEY@SU-SCORE.ARPA
cc: CSD@SU-SCORE.ARPA, TOM@SU-SCORE.ARPA
In-Reply-To: <12168180800.25.EPPLEY@SU-SCORE.ARPA>
Message-ID: <12168194287.21.TOM@SU-SCORE.ARPA>
What about thursday and friday to make it complete...
tom
-------
∂18-Dec-85 1659 TREITEL@SUMEX-AIM.ARPA date on 3600s
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 16:59:28 PST
Date: Wed 18 Dec 85 16:56:14-PST
From: Richard Treitel <TREITEL@SUMEX-AIM.ARPA>
Subject: date on 3600s
To: mjh-lispm@SU-AI.ARPA
cc: treitel@SUMEX-AIM.ARPA
Message-ID: <12168210429.31.TREITEL@SUMEX-AIM.ARPA>
For some unknown reason, when we brought our 3600's up today, all five of them
believed it was November 18th 1985 (they had the time of day right, at least!).
I have manually reset four of them to December, but was unable to get to Coax
and change its date. So whoever next has the chance, please ...
- Richard
-------
∂18-Dec-85 1727 @SU-SCORE.ARPA:welch@ames-vmsb.ARPA SIGBIG
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 17:27:16 PST
Received: from ames-vmsb.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Dec 85 17:21:47-PST
Date: 18 Dec 85 16:50:00 PST
From: welch@ames-vmsb.ARPA
Subject: SIGBIG
To: super@su-score.arpa
Reply-To: welch@ames-vmsb.ARPA
ASSOCIATION FOR COMPUTING MACHINERY
San Francisco Golden Gate Chapter
"SIGBIG" Special Interest Committee
For Large High Speed Computers
Meetings on the first Wednesday of each month at 7:30 PM. Speakers
who can give insights to various aspects of SUPERCOMPUTING are
featured each month.
Next meeting: Wednesday, January 8,1986, 7:30 PM
Speaker: Bob Hedges / Elxsi
Topic: Elxsi Systems and Supercomputing
Location: AXIOM Systems
1589 Centre Pointe Drive
Milpitas, CA
Directions: 17 South to Montague Expressway East. Left from
Montague onto Centre Point (before Capitol).
or 17 South to Capitol Expressway East. Right from
Capitol onto Centre Point (before Montague).
or 680 South to Montague Expressway West. Right from
Montague onto Centre Point (after Capitol).
---------------------------------------------------------------
Tape-recordings of most of the previous may be obtained
in exchange for a tape cassette or $5.00 by contacting:
Mary Fowler (415)261-4058 (rec)
Supercomputing #192, BOX 2787
Alameda, CA. 94501-0787
For information contact Mary Fowler, Chairperson (415) 839-6547
or Mike Austin, Publ. Chair (415) 423-8446
------
∂18-Dec-85 2105 JODY@SU-CSLI.ARPA Burrito Bandito
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 21:05:39 PST
Date: Wed 18 Dec 85 21:01:59-PST
From: Joe Zingheim <JODY@SU-CSLI.ARPA>
Subject: Burrito Bandito
To: folks@SU-CSLI.ARPA
Friends of the Burrito Bandito will be happy to hear that he has once again
eluded the Border Patrol and the INS, and will once again visit the Center
for one (perhaps last) time. Tacos, soft shelled, and the huge burritos will
be available, plus, perhaps, tamales (a south of the border season treat).
Sorry for the lack of advanced notice about this, but the sanctuary movement
is understandably unpredictable. With these you may not need the pillow to
augment your Santa Claus costume.
Further notice tomorrow morning with options for the un-initiated.
-------
∂19-Dec-85 1129 JODY@SU-CSLI.ARPA Burrito Bandito's visit
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 11:27:21 PST
Date: Thu 19 Dec 85 10:55:37-PST
From: Joe Zingheim <JODY@SU-CSLI.ARPA>
Subject: Burrito Bandito's visit
To: folks@SU-CSLI.ARPA
Burritos and tacos are available with:
Chile Verde with rice
Chile Colorado with beans
Chicken with rice
Tongue with rice
Carnitas with beans
Picadillo with beans
Chile Relleno with rice
Carne Asada with beans
Regular burritos cost $3.00
Special burritos (with sour cream, avacado, and cheese) $3.75
Tacos are $1.75
Send your request by replying to this, or send me mail -- Jody
-------
∂19-Dec-85 1204 @MCC.ARPA:francois%mcc-db.ARPA@mcc.ARPA list nail
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 12:04:42 PST
Received: from MCC.ARPA by su-aimvax.arpa with Sendmail; Thu, 19 Dec 85 11:59:40 pst
Received: from mcc-db.ARPA by MCC.ARPA with TCP; Thu 19 Dec 85 13:59:04-CST
Date: Thu, 19 Dec 85 13:59:36 cst
From: Francois Bancilhon <francois%mcc-db.ARPA@mcc.ARPA>
Posted-Date: Thu, 19 Dec 85 13:59:36 cst
Message-Id: <8512191959.AA07225@mcc-db.ARPA>
Received: by mcc-db.ARPA (4.12/4.22)
id AA07225; Thu, 19 Dec 85 13:59:36 cst
To: nail%diablo@mcc.ARPA
Subject: list nail
∂19-Dec-85 1205 @MCC.ARPA:francois%mcc-db.ARPA@mcc.ARPA list nail2
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 12:05:31 PST
Received: from MCC.ARPA by su-aimvax.arpa with Sendmail; Thu, 19 Dec 85 12:01:20 pst
Received: from mcc-db.ARPA by MCC.ARPA with TCP; Thu 19 Dec 85 13:59:34-CST
Date: Thu, 19 Dec 85 14:00:04 cst
From: Francois Bancilhon <francois%mcc-db.ARPA@mcc.ARPA>
Posted-Date: Thu, 19 Dec 85 14:00:04 cst
Message-Id: <8512192000.AA07243@mcc-db.ARPA>
Received: by mcc-db.ARPA (4.12/4.22)
id AA07243; Thu, 19 Dec 85 14:00:04 cst
To: nail%diablo@mcc.ARPA
Subject: list nail2
∂19-Dec-85 1233 EM@SU-SCORE.ARPA Common Lisp - Graphics.
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 12:33:30 PST
Date: Thu 19 Dec 85 12:30:00-PST
From: Eric Muller <EM@SU-SCORE.ARPA>
Subject: Common Lisp - Graphics.
To: mjh-lispm@SU-AI.ARPA
Message-ID: <12168424106.18.EM@SU-SCORE.ARPA>
Two questions to our expert community.
1. Do I pay a penalty by writting Common Lisp code insteas of Zeta Lisp ?
More precisely, are there CL constructs that do not translate well
in ZL, either because it is not possible or because the Symbolics CL
do not implement them efficiently right now ? Are there some typical
schemas that are well coded in CL style, do not execute efficiently
now, and can be coded in a more efficient way (even if this means
calling some ZL functions, provided that I can hide this and not
sacrifice the CL style) ?
2. I would like to make something similar to the data inspector;
instead of inspecting lisp objects, it would inspect logic formulas. In
this case, the mouse sensitive areas would be the subexpressions. The
user must have the ability to designate subexpressions, and then to
activate some functions that use these subexpressions and produce new
formulas. Of course, one need some form of scrolling because there are
more formulas than the screen can hold; also, it would be nice if the
set of formula to be displayed could be variable (i.e. the user
selects which formulas he wants to see in the window). Where must I
look to know if I can do something simple (I had a look at vol 7 of
the documentation, but it is not clear how I can implement the
selection mechanism I want) ? Is it possible to look at the code of
the data inspector (and if so, where is it) ? Am I trying to reinvent
the moon ?
thanks very much for your help,
eric.
p.s. Should I send this message to KSL-LispM as well ?
-------
∂19-Dec-85 1533 EMMA@SU-CSLI.ARPA Newsletter December 19, No. 6
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 15:33:26 PST
Date: Thu 19 Dec 85 15:11:49-PST
From: Emma Pease <Emma@SU-CSLI.ARPA>
Subject: Newsletter December 19, No. 6
To: friends@SU-CSLI.ARPA
Tel: 497-3479
!
C S L I N E W S L E T T E R
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
December 19, 1985 Stanford Vol. 3, No. 6
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
←←←←←←←←←←←←
CSLI ACTIVITIES FOR THURSDAY, January 9, 1986
12 noon TINLunch
Ventura Hall Some Remarks on How Words Mean
Conference Room by Georgia Green
Discussion led by Susan Stucky
(Abstract will be in the next newsletter)
2:15 p.m. CSLI Seminar
Whither CSLI? II
John Perry, CSLI Director
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
None planned
--------------
ANNOUNCEMENT
Please note that the seminar and colloquium are no longer in Redwood
Hall room G-19. The new location will be announced in early January.
Please also note that no activities are planned for December 19 and
26. Activities and the newsletter will resume January 9.
--------------
TALK ON JANUARY 2
On Thursday, January 2 at 2:15, Alexis Manaster-Ramer will discuss
``Finding Natural Languages a Home in Formal Language Theory''
(coauthored with William C. Rounds and Joyce Friedman, abstract to be
distributed later). The talk will be in Ventura Hall.
--------------
TENTATIVE WINTER QUARTER SCHEDULE
THURSDAY SEMINARS:
Date Speaker or Organizer
January 9 John Perry
January 16 Embedded Computation: Research on Situated Automata
January 23 Embedded Computation: Semantically Rational Computer
Languages
January 30 Helene Kirchner
February 6 Embedded Computation: Representation and Reasoning
February 13 Semantics of Computational Languages
February 20 Carol Cleland
February 27 Linguistic Approaches to Computer Languages
March 6 Mats Rooth
!
Page 2 CSLI Newsletter December 19, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
THURSDAY COLLOQUIA: (one colloquium during each period)
Time Organizers
January 9 to January 23: Embedded Computation group and
Document Preparation group
January 30 to February 13: Embedded Computation group,
Computational Language Semantics group and
Linguistic Approaches to Computer Languages
group
--------------
INTERACTIONS OF MORPHOLOGY, SYNTAX, AND DISCOURSE
Pronominal Incorporation in Finnish Possessives
Jonni Kanerva, (jkanerva@csli.arpa)
Thursday, December 19, 10:00, Ventura Conference Room
A class of five morphemes in Finnish, traditionally called
possessive suffixes (henceforeward Px), raises interesting questions
about the relationship of morphological structure to syntactic
functions. Px's appear to be pronominal, anaphoric, or even
agreement-like elements that occur on nominals and nonfinite verbs
following case suffixes. They are important syntactically: among
other things, they occur as possessors of nouns and as subjects of
nonfinite clauses. The very importance of Px's in the syntax tempts
one to analyse them as syntactic units---clitics---that are joined
phonologically to host words, as two recent analyses have done.
Nonetheless, a number of facts in Finnish indicate that these
syntactic functions are born by truly morphological
units---suffixes---rather than clitics.
I argue from phonological, morphological, and semantic evidence.
First, any allomorphy or phonological alternation in Finnish that is
sensitive to word boundaries treats the undisputed suffixes and the
Px's alike as being inside the word and treats a class of clitics as
being outside the word. Second, the occurrence of Px's is sometimes
dependent on the specific morphological structure of the stem. Third,
a large number of semantically idiosyncratic lexical items containing
Px's provide further support for a suffixal analysis of Px's, insofar
as suffixes are more susceptible to idiosyncratic lexicalization than
clitics. I argue next against the possibility that Px's are lexical
level clitics (i.e., clitics that attach to words at the morphological
level) by showing that it is quite costly to the theory of lexical
phonology to have a lexical level in Finnish that contains all of the
undisputed suffixes yet excludes the Px's; hence Px's must occupy the
same lexical level as other suffixes. Considering, then, all of the
evidence favoring a suffixal analysis for the Px's, especially the
morphological interactions between Px's and their stems, it is
extremely weak to set Px's apart from the other suffixes solely on the
basis of morpheme order. This indicates that the Px's are indeed
suffixes and therefore that a syntactic analysis of Px's should be
consistent with this finding.
!
Page 3 CSLI Newsletter December 19, 1985
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
SUMMARY OF A CSLI TALK
Agreement in Arabic, Binding and Extended Coherence
Abdelkader Fassi Fehri, (Fehri@csli.arpa)
We provide a fragment of a conceptual framework in which agreement
phenomena can be naturally characterised in correlation with
grammatical functions, and the appropriate well-formedness constraints
on functional structres would have as an effect to rule out agreement
relations that are unlikely to occur in natural languages. More
specifically, we assume a taxonomy of grammatical functions
distinguishing three classes: lexical and nuclear grammatical
functions (Subj, Obj, Obl, ...), non-lexical but nuclear grammatical
functions (Adjunct, Modifier), and non-lexical non-nuclear (Top, Foc,
...). Non-lexical non-nuclear grammatical functions are some times
called discourse functions or DFs. We argue that Coherence, whose
initial essential role in KB was to ensure the duplication in the
syntax of lexical-government relations, should be redefined to extend
to non-lexical nuclear as well as non-lexical non-nuclear grammatical
functions. We furthermore argue for a typology of agreement
distinguishing `grammatical' agreement (GAgr) from `anaphoric'
agreement (AAgr). GAgr is with lexical grammatical functions, AAgr
with non-lexical grammatical functions. Our proposal is that what
appears to be an anaphoric agreement marker is in fact an incorporated
pronoun. The different types of agreement fall out as effects of our
Extended Coherence Condition plus other independently motivated
well-formedness conditions on functional structures.
-------
∂19-Dec-85 1601 TAJNAI@SU-SCORE.ARPA Happy Holidays!
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 16:01:17 PST
Date: Thu 19 Dec 85 15:55:07-PST
From: Carolyn Tajnai <TAJNAI@SU-SCORE.ARPA>
Subject: Happy Holidays!
To: CSD@SU-SCORE.ARPA
Message-ID: <12168461448.44.TAJNAI@SU-SCORE.ARPA>
*
↑ With warm greetings and
↑↑↑ renewed hopes for
↑*↑↑↑ peace, contentment and joy in
↑*↑↑↑↑↑↑* the coming year.
↑↑↑↑↑↑↑↑↑↑↑
*↑↑↑↑↑*↑↑↑↑↑↑
↑↑↑*↑↑↑↑↑↑*↑↑↑↑ Carolyn and Ann
↑↑↑↑↑↑*↑↑↑↑↑↑↑↑↑↑
↑↑↑↑↑*↑↑↑↑↑↑↑*↑↑↑↑↑ and
↑↑↑↑↑↑↑↑↑↑↑*↑↑↑↑↑↑*↑↑
↑↑↑*↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑* the Forum
↑↑↑↑↑↑↑↑↑↑*↑↑↑↑↑↑↑↑↑↑↑↑↑↑
↑*↑↑↑↑↑↑↑↑↑↑↑*↑↑↑↑*↑↑↑↑↑↑↑↑
↑↑↑↑↑↑↑↑*↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑*↑↑↑↑
↑↑↑↑↑*↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑*↑↑↑↑↑↑↑↑
↑↑↑*↑↑↑↑↑↑↑↑*↑↑↑↑↑↑↑*↑↑↑↑↑↑↑↑*↑↑↑
↑*↑↑↑↑↑*↑↑↑↑↑↑↑↑*↑↑↑↑↑↑↑↑↑↑*↑↑↑↑↑↑↑
/\/\/\/\/\
/\/\/\/\/\
/\/\/\/\/\
-------
∂19-Dec-85 1730 YAMARONE@SU-CSLI.ARPA No Lunch Friday, 20th
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 17:30:11 PST
Date: Thu 19 Dec 85 17:26:00-PST
From: Tom Yamarone <YAMARONE@SU-CSLI.ARPA>
Subject: No Lunch Friday, 20th
To: folks@SU-CSLI.ARPA
The Ventura Sandwich Corp. is on vacation......
Service will resume Monday, December 30th.
Happy Holidays and for those who use this term,
MM MM EEEEEEEEE RRRRRRR RRRRRRR Y Y
M M M M E R R R R Y Y
M M M M E R R R R Y Y
M M M M E R R R R YY
M M M EEEEEE RRRRRRR RRRRRRR YY
M M E R R R R YY
M M E R R R R YY
M M E R R R R YY
M M EEEEEEEEE R R R R YY
CCCC H H RRRRR III SSSS TTTTTTTTT MM MM A SSSS
C C H H R R I S S T M M M M A A S S
C H H R R I S T M M M M A A S
C HHHHHHHH RRRRR I SSSS T M MM M AAAAAAA SSSS
C H H R R I S T M M A A S
C C H H R R I S S T M M A A S S
CCCC H H R R I SSSS T M M A A SSSS
-------
∂19-Dec-85 1835 @SU-SCORE.ARPA:ullman@su-aimvax.arpa intellectual property contract
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 18:35:46 PST
Received: from su-aimvax.arpa by SU-SCORE.ARPA with TCP; Thu 19 Dec 85 18:31:45-PST
Received: by su-aimvax.arpa with Sendmail; Thu, 19 Dec 85 18:34:34 pst
Date: Thu, 19 Dec 85 18:34:34 pst
From: Jeff Ullman <ullman@diablo>
Subject: intellectual property contract
To: faculty@score
I've been talking with various people connected with the
Committee on Research, on which I sit, about the department's
concerns over the new contract. I know a few people have mentioned
some concrete problems, either with the contract or with the
policy that it appears to enforce. Can any of you who have
concerns please refresh my memory? Chapter and verse where possible.
---Jeff
∂20-Dec-85 1154 SCHOLZ@SU-SUSHI.ARPA database seminar
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 20 Dec 85 11:50:32 PST
Received: from SU-SUSHI.ARPA by su-aimvax.arpa with Sendmail; Fri, 20 Dec 85 11:25:30 pst
Date: Fri 20 Dec 85 11:22:21-PST
From: Karin Scholz <SCHOLZ@SU-SUSHI.ARPA>
Subject: database seminar
To: wiederhold@SUMEX-AIM.ARPA, nail@SU-AIMVAX.ARPA, mugs@SUMEX-AIM.ARPA,
winslett@SU-SCORE.ARPA
Cc: milton@SRI-KL.ARPA
Message-Id: <12168673934.16.SCHOLZ@SU-SUSHI.ARPA>
since jack milton has graciously volunteered to maintain the mailing list
for the seminar, it should be a simple matter to schedule the speakers.
marianne winslett and i will be helping to coordinate the scheduling.
the current plan is to have each of the three involved research groups
deliver three seminars each. it could make the seminar series more
logically continuous to have each group scheduled for three consecutive
weeks, but it might give people a greater understanding of each other's wor
earlier on if we interleave the groups.
i propose the following schedule:
jan 10 gio
jan 17 jeff
jan 24 mike
jan 31 gio
.
.
.
the groups should decide among themselves who will be speaking on which
dates.
speaker and title should be sent to contreras@score by the monday morning
of the week before the seminar.
milton@sri needs an abstract 1 week in advance.
i am far away and won't be back until mickey's big hand is on the 86,
so if people have suggestions or objections to this schedule, please
work it out with marianne (sorry marianne).
the first week's speaker should send notice to contreras@score as soon
as she is committed. likewise, the first nail group speaker (how bout
you, naughton?) will need to send notice by jan 6.
thanks everyone.
karin
-------
∂20-Dec-85 1158 @SU-SCORE.ARPA:FEIGENBAUM@SUMEX-AIM.ARPA Re: intellectual property contract
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Dec 85 11:58:24 PST
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Dec 85 08:43:25-PST
Date: Fri 20 Dec 85 08:46:09-PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.ARPA>
Subject: Re: intellectual property contract
To: ullman@SU-AIMVAX.ARPA, faculty@SU-SCORE.ARPA
In-Reply-To: Message from "Jeff Ullman <ullman@diablo>" of Thu 19 Dec 85 19:29:08-PST
Message-ID: <12168645500.30.FEIGENBAUM@SUMEX-AIM.ARPA>
Thanks, Jeff. I've been oblivious to what has been going on re the
intellectual property contract issue. I would appreciate being copied
on the responses to Jeff's message (so I can be an informed signer or
non-signer).
Ed F.
-------
∂20-Dec-85 1200 @SU-SCORE.ARPA:ullman@su-aimvax.arpa GMD visit
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Dec 85 11:59:53 PST
Received: from su-aimvax.arpa by SU-SCORE.ARPA with TCP; Fri 20 Dec 85 09:57:06-PST
Received: by su-aimvax.arpa with Sendmail; Fri, 20 Dec 85 09:59:56 pst
Date: Fri, 20 Dec 85 09:59:56 pst
From: Jeff Ullman <ullman@diablo>
Subject: GMD visit
To: faculty@score
We're still expecting a visit from the GMD folks on Jan. 8.
Our plan is to have brief (say 20-30 minute) presentations
from faculty who might be interested in participating in the
institute. There will be technical people along on the
visit, so the presentation can be geared accordingly.
Apparently, they are most interested in new initiatives,
rather than supporting preexisting projects, and they
appear to be interested in interdisciplinary (or really inter-sub-disciplinary
work within CS) projects. Thus, two or more people might wish
to team up on a proposal.
I have so far heard expressions of interest from Gio, Vaughan,
Nils, Terry, and Ernst. I hope I'm not forgetting people,
but if I am, please let me know. Also, if you want a time slot,
please arrange one with Anne Richardson (richardson@score),
who is going to keep the schedule.
---Jeff
∂20-Dec-85 1425 RICHARDSON@SU-SCORE.ARPA Closing Early
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Dec 85 14:25:42 PST
Date: Fri 20 Dec 85 14:17:20-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Closing Early
To: csd@SU-SCORE.ARPA
Message-ID: <12168705791.10.RICHARDSON@SU-SCORE.ARPA>
Betty Scott asked me to let you know that CSD offices will close at
4:00 p.m. today.
-------
∂20-Dec-85 1610 ullman@su-aimvax.arpa paper available
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 20 Dec 85 16:10:17 PST
Received: by su-aimvax.arpa with Sendmail; Fri, 20 Dec 85 16:06:23 pst
Date: Fri, 20 Dec 85 16:06:23 pst
From: Jeff Ullman <ullman@diablo>
Subject: paper available
To: nail@diablo
Reprints of my recent TODS paper "Implementation of Logical
Query Languages for Databases" have been received.
If anybody at Stanford wants one, come by.
If someone off campus wants one, please write send mail to
rfn@sail, or as Arthur Keller would say: rfn@SU-AI.ARPA.
∂22-Dec-85 1505 ACUFF@SUMEX-AIM.ARPA Re: Common Lisp - Graphics.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 22 Dec 85 15:02:35 PST
Date: Sun 22 Dec 85 15:02:21-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Re: Common Lisp - Graphics.
To: EM@SU-SCORE.ARPA, mjh-lispm@SU-AI.ARPA
In-Reply-To: <12168424106.18.EM@SU-SCORE.ARPA>
Message-ID: <12169238274.30.ACUFF@SUMEX-AIM.ARPA>
I believe there are very few local expert users of Common Lisp.
However, you should be safe using Symbolics Common Lisp. As always,
implement whatever in the cleanest, way you can, and then, if
necessary, try to hack it for efficiency. Since there is no graphics
in Common Lisp, you will have to resort to ZetaLisp (or rather
"Symbolics extentions to Common Lisp") to accomplish your goals.
You can look at the code of the Inspector by doing M-. on INSPECT.
-- Rich
-------
∂23-Dec-85 1605 GINN@SUMEX-AIM.ARPA Please
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 23 Dec 85 16:04:43 PST
Date: Mon 23 Dec 85 16:04:34-PST
From: Michael Ginn <GINN@SUMEX-AIM.ARPA>
Subject: Please
To: mjh-lispm@SU-AI.ARPA
Message-ID: <12169511743.11.GINN@SUMEX-AIM.ARPA>
Please remove me from this list. I do NOT want it to go to my
e-mail file.
---Michael
-------
∂24-Dec-85 0828 @SUMEX-AIM.ARPA:ihnp4!kddlab!nttlab!NTT-20!Okuno@seismo.CSS.GOV Greeting
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 24 Dec 85 08:26:03 PST
Received: from seismo.CSS.GOV by SUMEX-AIM.ARPA with TCP; Tue 24 Dec 85 08:25:18-PST
Return-Path: <ihnp4!kddlab!nttlab!NTT-20!Okuno>
Received: from cbosgd.UUCP by seismo.CSS.GOV with UUCP; Tue, 24 Dec 85 11:11:22 EST
Received: from lc/garage/packard.DK
by cbosgd.ATT.UUCP (4.12/UUCP-Project/11.09.85)
id AA15783; Tue, 24 Dec 85 10:55:34 est
Date: 24 Dec 1985 1835
From: Hiroshi G. Okuno <ihnp4!kddlab!nttlab!NTT-20!Okuno@seismo.CSS.GOV>
Subject: Greeting
Message-Id: <8512240935.AA26501@ntt.junet>
Received: by ihnp4.ATT.UUCP id AA12430; 24 Dec 85 08:41:08 CST (Tue)
Received: by kddlabs.junet (4.12/4.7)
id AA23040; Tue, 24 Dec 85 18:37:11 jst
Received: by kddlabs.junet (4.12/4.7)
id AA23037; Tue, 24 Dec 85 18:37:06 jst
Received: by ntt.junet (4.12/4.7JC-5) CHAOS with CHAOS-MAIL
id AA26501; Tue, 24 Dec 85 18:35:02 jst
Received: from ihnp4.UUCP by lc/garage/packard.DK; 8512241556
To: hpp@sumex-aim.arpa
Cc: aap@sumex-aim.arpa
m m EEEEEE RRRRRrr RRRRRrr Yy yY
MM MM E R R R R Yy yY
M M M M EEEEEE RRRRRRr RRRRRRr YY
M MmM M E R R R R YY
M M EEEEEE R R R R YY
' ' ' ' ' ' ANGEL' ' ' Xx xX m m A SSSSSs
' ' ' ' ' ' ' ' ' ' X X MM MM A A S
' 'A ' 'D ' 'V ' '* ' ' X M M M M A A SSSSSS
' ' ' ' ' ' ' * ' ' X X M MmM M AAAAAAA s S
' ' A' 'N ' 'C ' t*#* ' xX Xx M M A A SSSSSS
' E ' D ' ' ' ' 'a**%**t '
' ' 'A ' ' 'o**%**$*a' RCHI' ' ' ' ' T ' E' 'C T ' ' '
' 'U ' ' R' ' i**KSL*SU*o' ' 'E ' ' ' ' ' S' 'P ' ' ' '
' ' R' ' ' s**$**%*#*%*t ' ' ' ' 'O ' ' ' ' ' J' 'E 'CT '
' ' ' ' ' s**%*#*%*$**%*h' ' '' ''' ' ' ' ' ' ' ' ' ' '
' ' T ' ' i**%*#*%*#*%*#**a' ' '' ' 'I ' ''N' ' ' ' ' ' ' 'A
' ' ' C' l**%*$*#*N*U*E**%*t ' ' ' ' ' ' ' 'A ' ' ' ' ' '
' ' ' 'e**%*#*%*#*%H$**%*#*i' ' ' ' ' ' ' ' ' ' ' ' ' ' '
' O' S' ' n**N*T*T**%*#P%*E*C*L*s '' ' ' ' ' ' ' ' L' ' ' ' ' '
' O' ' t**A*#*G**E*#*P**%*#*%**t ' 'Q 'E 'L ' ' ' ' ' ' ' '
' ' I ' 'l**%*| |**%*#*%*#*%**$**%*a ' ' ' ' ' ' ' ' N ' ' '
' ' ' a**%**| |*C**A**R**E**%*#*%*o ' ' T' L ' M ' ' ' ' ' '
'C 'R ' o**%**(←←|**%*#*%*$**%*#*%*#**e' ' ' ' ' ' ' ' 'Y '
'P 'T '**%*#*%*#*$**%*#*%*#*%*#*$**%**d ' ' O' C' L. ' ' o ' b' ' ' '
' ' ' i s 'n ' | |' o' 't ' t ' ' ' ' ' ' ' 'r ' '
' ' 'u ' ' t ' | | ' ' ' ' ao' ' ' ' ' ' ' ' '' g'
Happy New Year!
- Gitchang -
-------
∂25-Dec-85 1159 avg@su-aimvax.arpa acyclicity in recursive rules
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 25 Dec 85 11:59:38 PST
Received: by su-aimvax.arpa with Sendmail; Wed, 25 Dec 85 11:56:44 pst
Date: Wed, 25 Dec 85 11:56:44 pst
From: Allen VanGelder <avg@diablo>
Subject: acyclicity in recursive rules
To: nail@diablo
Here are some random observations on the role of acyclicity in recursive
rules.
The evaluation hypergraph of an adorned rule is formed by making a node
for the head of the rule that contains only the bound arguments. Nodes
for subgoals contain all arguments. Assume no function symbols or
constants appear in the rules. The evaluation hypergraph may or may not be
acyclic. When it is, it has a qual tree, and information passing in
accordance with the edges of the qual tree looks attractive.
Now look at the common ancestor (ca) problem.
Read ca(A, B, C) as "A and B have common ancestor C".
Read a(A, B) as "A has ancestor B".
Read p(A, B) as "A has parent B". This is the EDB, assumed to be a DAG.
One set of rules for ca (rules for a are standard):
ca(A,B,B) :- a(A,B).
ca(A,B,A) :- a(B,A).
ca(A,B,C) :- a(A,D), a(B,E), ca(D,E,C).
Look at the evaluation hypergraph for the recursive rule for ca↑bbf.
The nodes are:
ca↑b(A,B) a←1(A,D) a←2(B,E) ca(D,E,C)
This is clearly cyclic.
Now look at the evaluation hypergraph for the recursive rule for ca↑bff.
The nodes are:
ca↑b(A) a←1(A,D) ca(D,E,C) a←2(B,E)
This is acyclic, and has a qual tree that connects the nodes in the order
written.
Question: Does this imply that evaluating ca↑bbf is about as hard as
evaluating ca↑bff?
Another set of rules for ca (Now we show a also):
ca(A,B,C) :- a(A,C), a(B,C).
a(A,A).
a(A,B) :- p(A,X), a(X,B).
Look at the evaluation hypergraph for the rule for ca↑bbf.
The nodes are:
ca↑b(A,B) a←1(A,C) a←2(B,C)
This is clearly cyclic.
Now look at the evaluation hypergraph for the recursive rule for ca↑bff.
The nodes are:
ca↑b(A) a←1(A,C) a←2(B,C)
This is acyclic, and has a qual tree that connects the nodes in the order
written.
Merry Christmas and Happy New Year.
∂26-Dec-85 1519 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books--Computer Science
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 15:19:08 PST
Date: Thu 26 Dec 85 15:14:06-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books--Computer Science
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA, cs%Playfair@SU-SCORE.ARPA
Message-ID: <12170288988.15.LIBRARY@SU-SCORE.ARPA>
Machine-Independent Organic Software Tools (MINT) 2nd edition. by Godfrey,
Hendry, Hermans, and Hessenberg.QA76.6.M319 1982.
Artificial Intelligence: Towards Practical Apllication. GDI Technology
Assessment and Management. edited by Bernold and Albers. Q334.T43 1985 c.2
PORTAL Language Description. Lecture Notes In Computer Science. 198.
by Arnold Businger. QA76.73.P66.B87 1985.
IEEE Computer Society. Reliable Distributed System Software. by John
Stankovic. QA76.9.D5S73 1985.
Functional Programming Languages and Computer Architecture. Nancy,
France, Sept. 1985. Lecture Notes In Computer Science. 201. ed. by
Jouannaud.QA76.7F86 1985.
CAD of Concurrent Computers. Research Studies Press. by Patrick Foulk.
QA76.9.S88F68 1985.
International Workshop On Timed Petri Nets. Torino, Italy. July 1985.
QA267.I695 1985.
IEEE Computer Society. Conference on Computer Vision and Pattern
Recognition. June, 1985. TA1632.I36 1985.
12th Annual International Symposium on Computer Architecture.
June 1985. Boston, Mass. Proceedings.
CPEUG 16th Meeting. Computer Performance Evaluation Users Group.
QA76.9.E94C65 1980.
Applied Finite Mathematics And Calculus. by Kertz. QA37.2.K47 1985.
Interface: Calculus And the Computer. 2nd ed. by David Smith.
QA303.S596 1984 c.2
Discrete Structures: An Introduction to Mathematics For Computer
Science. by Fletcher Norris. QA76.9M35N67 1985.
Secure Communications And Asymmetric Cryptosystems. AAAS Selected
Symposium 69. ed. by Gustavus Simmons. Z103.S42 1982.
Reliability Theory And Models: Stochastic Failure Models, Optimal
Maintenacne Policies, Life Testing, and Structures. Notes and
Reports in Computer Science and Applied Mathematics. ed. by
Abdel-Hameed, Cinlar, and Quinn. TA169.R46 1984.
Prelude To Programming: Problem Solving and Algorithms. by
William Mitchell. QA76.6.M5294 1984.
Studies In Numerical Analysis. by Gene Golub. QA279.S83 1984.
Einfuhrung In Das Programmieren In LISP. by Christian-Michael
Hamann. QA76.73.L23H35 1982.
Information System Specification And Design Road Map. by Dennis
Connor. T58.6.C668 1985.
The Universal Machine. by Pamela McCorduck. QA76.M367 1985.
The Complete Guide To Software Testing. QED Information Sciences.
by William Hetzel. QA76.76.T48H48 1984.
File And Data-Base Management Programs for the IBM PC. by Myron
Hecht. QA76.8I2594H39 1985.
Assembly Language and Systems Programming for the IBM PB and
Compatibles. by Karen Lemone. QA76.8I2594L425 1985.
Dictionary of Microelectronics and Microcomputer Technology.
Deutsch/Englisch, English/German. Reference TK7804.A88 1984.
The Software Encyclopedia. 1985/86. Reference QA76.5S664 1985
volumes 1 and 2.
Harry Llull
-------
∂27-Dec-85 0951 LIBRARY@SU-SCORE.ARPA Math/CS Library New Books--Computer Science
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 27 Dec 85 09:50:26 PST
Date: Fri 27 Dec 85 09:46:30-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Math/CS Library New Books--Computer Science
To: su-bboards@SU-SCORE.ARPA
cc: faculty@SU-SCORE.ARPA, cs%Playfair@SU-SCORE.ARPA
Message-ID: <12170491494.11.LIBRARY@SU-SCORE.ARPA>
Heuristic Reasoning About Uncertainty: An Artificial Intelligence
Approach. Research Notes In Artificial Intelligence 2. by Paul R.
Cohen. Q375.C64 1985.
IEEE Workshop on Languages For Automation. Cognitive Aspects In
Information Processing. Spain. June 28-29, 1985. TJ212.2.I326 1985.
H. Llull
-------
∂27-Dec-85 1713 RICE@SUMEX-AIM.ARPA Tina
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 27 Dec 85 17:13:28 PST
Date: Fri 27 Dec 85 17:13:10-PST
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: Tina
To: aap@SUMEX-AIM.ARPA
Message-ID: <12170572808.14.RICE@SUMEX-AIM.ARPA>
A new version of the Tina system has been released. This has a number of
major changes. The new features of the system are documented in the new
release of the Tina System manual.
The new release of the manual can be found in the following :-
3602:>System-Software>Tina>Tina-System.Document
A small file which contains poi9nters to the deltas is in :-
3602:>System-Software>Tina>Changes.Document
I'm thinking about a proper printable form of the manual. Apologies to those
who like to read off line.
Rice.
-------
∂27-Dec-85 1905 FEHRI@SU-CSLI.ARPA
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 27 Dec 85 19:05:27 PST
Date: Fri 27 Dec 85 18:59:47-PST
From: Fassi fehri <FEHRI@SU-CSLI.ARPA>
To: folks@SU-CSLI.ARPA
cc: fehri@SU-CSLI.ARPA
I am leaving tomorrow evening, back to Morocco. I would like to thank you
all for your friendship, and especially those of you who made me feel
that no accident has happened. Bye and happy new year,
Abdu
-------
∂27-Dec-85 2008 ullman@su-aimvax.arpa meetings canceled
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 27 Dec 85 20:08:01 PST
Received: by su-aimvax.arpa with Sendmail; Fri, 27 Dec 85 20:04:25 pst
Date: Fri, 27 Dec 85 20:04:25 pst
From: Jeff Ullman <ullman@diablo>
Subject: meetings canceled
To: nail@diablo
I forgot to say that last Wednesday's meeting was canceled
on account of Christmas. I hope nobody showed up.
This Wednesday, being New Years, probably shouldn't have a
meeting either.
---Jeff
∂29-Dec-85 1047 PAPA@SU-SCORE.ARPA Concurrency Control Book
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 29 Dec 85 10:47:42 PST
Received: from SU-SCORE.ARPA by su-aimvax.arpa with Sendmail; Sun, 29 Dec 85 10:45:03 pst
Date: Sun 29 Dec 85 10:41:31-PST
From: C. Papadimitriou <PAPA@SU-SCORE.ARPA>
Subject: Concurrency Control Book
To: nail@SU-AIMVAX.ARPA
Message-Id: <12171025799.11.PAPA@SU-SCORE.ARPA>
Believe it or not, my book ``The Theory of Database Concurrency Control'' is
almost done. Its shape is final enough that I would like to have some
people with interest in the area look at it. If you are seriously interested
in looking at it in the next six weeks and give me your comments and
corrections, I would appreciate it. Please send me a message. I plan to
make about ten copies. The table of contents follows (in broken TeXese):
\input macros
\obeylines
\centerline{\bf CONTENTS}
\vskip .25 in
CHAPTER ONE: INTRODUCTION
1.1 Databases and Concurrency
1.2 The Model
APPENDIX: Notation, Graph Theory, Algorithms and Complexity.
\vskip .2in
CHAPTER TWO: CORRECTNESS
2.1 Introduction
2.2 Final-State Serializability
2.3 The Critics of Final-State Serializability
2.4 View Serializability
2.5 The Complexity of View Serializability
2.6 Conflict Serializability
2.7 Special Cases
\vskip.2in
CHAPTER THREE: MORE ON CORRECTNESS
3.1 Multiple Versions
3.2 Reliability
3.3 The Complexity of Reliability
\vskip.2in
CHAPTER FOUR: SCHEDULERS
4.1 Introduction
4.2 Locking
4.3 Structured Locking
4.4 Timestamp Scedulers
4.5 Conflict Graph Schedulers
4.6 Multiversion Schedulers
4.7 Deadlocks
4.8 Reliable Schedulers
\vskip.2in
CHAPTER FIVE: THE PERFORMANCE OF SCHEDULERS
5.1 Efficiency and Concurrency
5.2 Information and Concurrency
5.3 Multiversion Schedulers
\vskip.2in
CHAPTER SIX: THE THEORY OF LOCKING
6.1 Uninterpreted Locking
6.2 Entity Locks
6.3 Locking Protocols
6.4?? Deadlocks
\vskip .2in
CHAPTER SEVEN: DISTRIBUTED CONCURRENCY CONTROL
7.1 The Model
7.2 Distributed Schedulers
7.3 The Complexity of Distributed Concurrency Control
7.4 Distributed Locking
\vfill\end
-------
∂29-Dec-85 1452 NILSSON@SU-SCORE.ARPA End-of-year Note
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Dec 85 14:51:55 PST
Date: Sun 29 Dec 85 14:46:21-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: End-of-year Note
To: csd@SU-SCORE.ARPA
Message-ID: <12171070369.9.NILSSON@SU-SCORE.ARPA>
Dear Stanford computer scientists and friends of computer science at Stanford:
This is where I came in--one year ago--at the end of autumn quarter. I
only thought I knew a lot about the Computer Science Department then!
This end-of-the-year note is primarily to thank you all for helping to
make this an exciting year for me personally and a year of progress for
the department and for all of computer science everywhere at Stanford.
We have made some important achievements: moving the CSD to the School
of Engineering (it didn't hurt much, did it?); welcoming John Hennessy
back to Stanford to lead a new CSL that enjoys the enthusiastic support
of both EE and the CSD; designing a premier CS undergraduate curriculum
that many of us hope will be put in place next year; modernizing the
rest of the CS curriculum; upgrading CS student computing facilities;
beginning to restudy thoroughly our PhD requirements; and beginning an
updated, long-range plan for the department. We are particularly proud
of the many achievements of our outstanding students including their
winning the ACM programming competition.
I still have many things on my list that I wish we had made more
progress on. We still have only one endowed chair in the CSD. That has
to change! We still have too little space, and what we have is spread
around too much. Things will improve when we move into new quarters in
the Near West Campus (probably circa 1990), but in the meantime any
relief from overcrowding will probably spread us around even more. We
have had a search going for a robotics professor for almost a year, and
still our search committee has not found a suitable candidate. We are
facing the stresses of a proposed undergraduate major, and we have not
yet begun searching for the new faculty that will be required to staff
that major. Most of the CSD faculty and staff are stressed by needing
to do more than there is time to do it in. We can probably all point to
things that we wish had been accomplished in 1985 which just didn't get
done.
Well, there is always 1986! One of the major tasks before us
immediately at the beginning of 1986 is for us to decide do we or don't
we do the undergraduate major starting in September. We can talk about
the pros and cons of all of that some more at our faculty retreat on
January 4, and we'll have Jim Gibbons there to exlain how he is prepared
to commit resources to the program. In order to get all of the
necessary university approvals for the major, I think we will have to
decide formally one way or the other at our regular faculty meeting on
January 7. We will be making that decision in the context of
authorizations from Jim Gibbons to begin several new searches if we
decide in favor of the major.
Assuming we decide to do the major, we need to organize ourselves to
conduct some searches immediately (and to incorporate these new people
into the department in September--if we can get super-high quality
people by then). Although long-range plans are fine things, I suppose,
our only real guarantee of being a first-rate department in the future
is to have first-rate people. So we will have to be exceptionally
careful to ensure that we get them. Effort on that task is worth tons
of planning!
There are many other opportunities on the 1986 horizon including a
possible new GMD-sponsored institute in Palo Alto that could bring in
substantial additional research support for the CSD (GMD is a German
quasi-government research organization); and a possible new Center for
Parallel Computing. We expect to make progress on our planning for
computing facilities (hardware and software). We want to increase the
strength of our beneficial ties with local computer science research
establishments, and we look forward to productive cooperation with other
departments in our new home in the School of Engineering.
I'm sure that all of the faculty join me in expressing our deep
appreciation for the dedicated efforts of the staff. Even though we are
all working hard, a deserved compliment is rewarding both to its giver
and receiver and helps make all of our lives here more enjoyable. I'm
particularly pleased that the staff has elected two "staff bureaucrats"
who will help us in the administration listen helpfully to staff
concerns and will also keep their constituents informed about
administrative planning.
Best wishes for a happy and fulfilling 1986! -Nils
-------
∂30-Dec-85 1405 DAVIES@SUMEX-AIM.ARPA More IJCAI-85 articles of possible interest
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 30 Dec 85 14:05:29 PST
Date: Mon, 30 Dec 1985 14:04 PST
Message-ID: <DAVIES.12171324920.BABYL@SUMEX-AIM.ARPA>
From: DAVIES@SUMEX-AIM.ARPA
To: AAP@SUMEX-AIM.ARPA
Subject: More IJCAI-85 articles of possible interest
cc: Davies@SUMEX-AIM.ARPA
Y. Nishimoto and Y. Shirai: A parallel matching algorithm for stereo
vision. (p. 977) [Parallelism by subdividing an image]
Edmund H. Durfee, Victor R. Lesser, Daniel D. Corkill: Increasing
coherence in a distributed problem-solving network. (p. 1025)
[Improved local reasoning by sharing meta-level knowledge between
nodes]
Christopher Stuart: An implementation of a multi-agent plan
synchronizer. (p. 1031) [Using synchronizing primitives to resolve
conflicts between concurrent real-world actions]
Tom Henderson, Chuck Hansen, and Bir Bhanu: A framework for
distributed sensing and control. (p. 1106) [An architecture for
integrating information from multiple, possibly heterogeneous
sensors]
∂30-Dec-85 1441 NILSSON@SU-SCORE.ARPA Probable New Searches
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Dec 85 14:41:40 PST
Date: Mon 30 Dec 85 14:35:46-PST
From: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Subject: Probable New Searches
To: ac@SU-SCORE.ARPA
Message-ID: <12171330587.14.NILSSON@SU-SCORE.ARPA>
John Hennessy, Bob White and I had a productive meeting with Jim Gibbons
just before the Christmas break. Jim is preparing to commit his "six
billets" --or at least five of them--now. John Hennessy and I are
writing memos requesting search initiations, and these have to be
officially approved. I expect approval soon after the first of the
year.
Here's the breakdown:
1. A programming languages person (emphasizing, perhaps,
applicative and/or parallel languages)
2. A CAD (for VLSI) person
3. An AI person who wants to pursue basic AI research motivated
by engineering applications
4. A computer architecture or VLSI systems person
5. A theory-of-computer science person
All of these will also have to have evident interest in teaching,
including undergraduate teaching.
(These are also in addition to the systems and robotics searches
currently underway. Jim had also previously approved our reinstituting
a search--jointly with math--for an "applied math/scientific computing"
person.)
I think this is a good start, and now Jim can go to Rosse--saying he's
spending his six billets--requesting more to meet the rest of our growth
plan. These are probably even more searches than we can effectively
pursue for now, so I think it remains only to get reasonably firm
commitments to start additional searches (according to our planned
schedule) as we fill these slots. Of course these searches (and
additional promises) are contingent on the CSD faculty approving the
undergraduate program. I think progress is sufficient to bring the
matter to a vote at the first faculty meeting in January--given the
discussion that is bound to take place at the retreat on Jan. 4.
-Nils
-------
∂30-Dec-85 1843 @SU-SCORE.ARPA:coraki!pratt@su-navajo.arpa Re: Probable New Searches
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Dec 85 18:43:25 PST
Received: from su-navajo.arpa by SU-SCORE.ARPA with TCP; Mon 30 Dec 85 18:39:49-PST
Received: by su-navajo.arpa with Sendmail; Mon, 30 Dec 85 18:39:55 pst
Received: by coraki.uucp (1.1/SMI-1.2)
id AA13423; Mon, 30 Dec 85 18:35:16 pst
Date: Mon, 30 Dec 85 18:35:16 pst
From: coraki!pratt@su-navajo.arpa (Vaughan Pratt)
Message-Id: <8512310235.AA13423@coraki.uucp>
To: Nils Nilsson <NILSSON@SU-SCORE.ARPA>
Cc: ac@su-score.ARPA, pratt@su-navajo.arpa
Subject: Re: Probable New Searches
In-Reply-To: message of Mon 30 Dec 85 14:35:46-PST.
<12171330587.14.NILSSON@SU-SCORE.ARPA>
I don't see any slots for logic. It is an absolute certainty that this
is an area in which Stanford must grow in order for us not merely to
keep pace with the world but to push it along. It is critical that we
recognize logic as a subject that has not only played an important role
to date in computer science but will further increase in importance as
the ways in which we manipulate information structures become
progressively more abstract.
-v
∂31-Dec-85 1642 RICE@SUMEX-AIM.ARPA Hard Copy Tina docs.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 31 Dec 85 16:42:00 PST
Date: Tue 31 Dec 85 14:36:39-PST
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: Hard Copy Tina docs.
To: aap@SUMEX-AIM.ARPA, bhayes-roth@SUMEX-AIM.ARPA, hewett@SUMEX-AIM.ARPA
Message-ID: <12171592892.22.RICE@SUMEX-AIM.ARPA>
The L100 and Tina manuals are now available in hard copy form with all
of the special characters readable. If you want a copy please could you
send me a note so that I'll know how many copies to run off.
As before the new versions of these manuals in their on line form are in
3602:>System-Software>L100>L100-Language-Manual.Document
and
3602:>System-Software>Tina>Tina-System.Document
respectively. Your feedback on these would be much appreciated. I would
like them to be useful.
Rice.
-------
∂31-Dec-85 1642 RICE@SUMEX-AIM.ARPA Printing out Tina models.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 31 Dec 85 16:42:21 PST
Date: Tue 31 Dec 85 15:43:02-PST
From: Jim Rice <RICE@SUMEX-AIM.ARPA>
Subject: Printing out Tina models.
To: aap@SUMEX-AIM.ARPA
Message-ID: <12171604975.22.RICE@SUMEX-AIM.ARPA>
This message is for those who are going to write Tina models.
If you would prefer to use the special character representation of the
operator characters in Tina and would like to print out your model then
you should load "3602:>Tools>Make-Into-Scribe-File" and then use the
procedure (Make-Into-Scribe-File infile outfile). This will make an output
file in Scribe format which will display the special characters in their
true form.
This program will cope with all Lisp machine special characters, not just
those used by Tina.
Rice.
-------
∂31-Dec-85 1652 RICHARDSON@SU-SCORE.ARPA General Faculty Meeting
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 31 Dec 85 16:52:39 PST
Date: Tue 31 Dec 85 08:09:54-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: General Faculty Meeting
To: faculty@SU-SCORE.ARPA
cc: gotelli@SU-SCORE.ARPA, woodward@SU-SCORE.ARPA
Message-ID: <12171522485.13.RICHARDSON@SU-SCORE.ARPA>
There will be a general faculty meeting on Tuesday, Jan. 7, 1985
at 2:30 in MJH 146. The known agenda items include: 1/ conferral
of degrees and 2/ a decision about the UG major. If you have any
additional agenda items, please forward them to me.
Thanks,
Anne
-------
∂31-Dec-85 1653 BSCOTT@SU-SCORE.ARPA [Phyllis M. Hughes <AS.PHU@Forsythe>: Army Research Office Announcement Coming: Pls Advise Clients]
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 31 Dec 85 16:53:00 PST
Date: Tue 31 Dec 85 08:25:00-PST
From: Betty Scott <BSCOTT@SU-SCORE.ARPA>
Subject: [Phyllis M. Hughes <AS.PHU@Forsythe>: Army Research Office Announcement Coming: Pls Advise Clients]
To: AC@SU-SCORE.ARPA
Message-ID: <12171525233.14.BSCOTT@SU-SCORE.ARPA>
Are any of you interested in this announcement from the USARO? Let me know
if you are, and I will get more information. - Betty
---------------
Return-Path: <AS.PHU@Lindy>
Received: from Lindy by SU-SCORE.ARPA with TCP; Mon 30 Dec 85 10:31:44-PST
Date: Mon, 30 Dec 85 10:34:46 PST
From: Phyllis M. Hughes <AS.PHU@Forsythe>
To: BSCOTT@SCORE
Subject: Army Research Office Announcement Coming: Pls Advise Clients
Bridget Morgan, Gary McDonough, Betty Scott, Dena Polyhronakis:
Please share with appropriate PI's in your department.
P.Hughes 12/30/85
To: FA.BCM, BSCOTT@SCORE, FE.DXP
FORWARDED MESSAGE 12/20/85 07:40 FROM AS.CFB "Fred Bentley": Army Research
Office Announcement Coming: Pls Advise Clients
Val and Phyllis:
I believe that you may also have an interest in this announcement.
Fred
To: AS.VGM, AS.PHU, HK.EGC
FORWARDED MESSAGE 12/19/85 10:08 FROM HK.EGC "Earl Cilley": Army Research
Office Announcement Coming: Pls Advise Clients
ARO ANNOUNCES URI RESEARCH CENTERS
On December 12 the Army Research Office (ARO) published in the
Commerce Business Daily notice of its plans for the Army version
of the University Research Initiative. The Army is inviting
proposals in the ten research areas listed below. Awards are
planned, subject to available appropriations, in amounts up to
$3M per year for five years. Funds will be provided for
fundamental research, graduate fellowships and research
instrumentation. On December 27 ARO will publish a Broad Agency
Announcement. Proposals will be due on February 28. The ten
areas of interest are: biosystems and biotechnology, geosciences,
electro-optics, signal processing and image understanding, high
frequency microelectronics, fast reaction kinetics of energetic
materials, advanced propulsion systems, intelligent control
systems, ultradynamic performance materials, manufacturing
science and reliability and maintainability enhancement, and
advanced construction technology.
To: AS.GUS, MCCABE@SIERRA, AS.PLB, AS.RMK, AS.SDG, AS.CFB
cc: HK.PLD, HK.KDC
-------
∂31-Dec-85 1657 @SU-SCORE.ARPA:ullman@su-aimvax.arpa Re: Gordon Bell
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 31 Dec 85 16:57:46 PST
Received: from su-aimvax.arpa by SU-SCORE.ARPA with TCP; Tue 31 Dec 85 10:09:27-PST
Received: by su-aimvax.arpa with Sendmail; Tue, 31 Dec 85 10:12:56 pst
Date: Tue, 31 Dec 85 10:12:56 pst
From: Jeff Ullman <ullman@diablo>
Subject: Re: Gordon Bell
To: RICHARDSON@SU-Score, ac@SU-Score
Id like to talk with him for a short time.
∂31-Dec-85 1657 RICHARDSON@SU-SCORE.ARPA Gordon Bell
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 31 Dec 85 16:57:32 PST
Date: Tue 31 Dec 85 09:41:55-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Gordon Bell
To: ac@SU-SCORE.ARPA
Message-ID: <12171539237.13.RICHARDSON@SU-SCORE.ARPA>
Gordon Bell will be visiting the Stanford CSD on Jan. 8 ( in addition to
being the colloquium speaker for CS 500 on Jan. 7 ). If anyone would like
to see him, please let me know.
-Anne
-------
∂31-Dec-85 1655 RICHARDSON@SU-SCORE.ARPA Happy New Year
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 31 Dec 85 16:55:18 PST
Date: Tue 31 Dec 85 08:33:36-PST
From: Anne Richardson <RICHARDSON@SU-SCORE.ARPA>
Subject: Happy New Year
To: csd@SU-SCORE.ARPA
Message-ID: <12171526798.13.RICHARDSON@SU-SCORE.ARPA>
Betty Scott asked me to let you know that the CSD offices will close at
3:00 p.m. today.
-------